Achim Spangler wrote:
> 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?
I dunno. I don't recall fixes in this area, but that means nothing -- 1.5.0
has been underway since the parting of the Red Sea.
> 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).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-26 21:41:37 CET