Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.4.x
-
None
Description
Hi, in my project http://www.isoaglib.org, we use svn:external properties to achieve access control for parts of an anonymous accessible repository. We have several "svn:externals" properties distributed over some directories, so that a "svn co" or "svn up" sequence is finished with a list of "svn:externals" retrievals. Some users have only access right for a subset of the "svn:externals"-connected resources. Example Structure: Root | | | -- dir1 - external1 | | | -- dir1.2 | -- dir2 - external2 | -- dir2.2 User FOO has only access right for external2. Problematic current (Version: 1.4.3) SVN behaviour: svn co/up aborts as soon as the first resource is not accessible, so that the later defined svn:externals are not even tried. In example: User FOO does not get access to external2, as svn up/co aborts at external1 due to missing access rights. Wanted behaviour: Each svn:externals should be tried, and all unsuccessful entries should be reported at the end. In example: User FOO should get checkout and update including external2, and a final report should state failed access to external1 This is from my understanding a svn-client problem. Question: 1) Has this been fixed since Version 1.4.3? 2) Is there some reason for the current behaviour? 3) Am I the only user with such a setup? ( I found already some comparable results - but not yet any response or plan for solving of this issue ) Thanks, Achim =============== This report has been sent to dev-list before. "C. Michael Pilato" <cmpilato@collab.net> (CollabNet, Inc.) supported my request and provided following further example, where current behaviour causes problems: > 2) Is there some reason for the current behaviour? The default error handling paradigm in the Subversion codebase is to bubble errors up to the top of the call stack. Chances are good that the behavior you are seeing is just the result of some coder not anticipating or valuing the use case. > 3) Am I the only user with such a setup? > ( I found already some comparable results - but not yet any response or > plan for solving of this issue ) You certainly aren't the only user using svn:externals, and the problems you describe aren't necessarily unique to your situation anyway. A fetch of an external location could fail for any reason, such as a working copy on a not-connected-to-the-net laptop checked out from a local repository that has externals definition pointing to some remote repository. The question becomes, "What do we do when a checkout/update of an external working copy fails?" I personally think you've a point here -- reporting the error but moving on to attempt further externals checkouts might be the kinder thing to do, especially if the logic is able to gracefully subsequent retries of the same update where the externals checkouts *don't* fail (considering again the laptop, who is now connected to the 'Net).
http://svn.collab.net/repos/svn/branches/issue-3148-dev/BRANCH-README
Original issue reported by spangler