Too early svn up/co abort if one item of svn:external resource list is not accessible

[Achim Spangler <Ac...@mnet-online.de>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Too early svn up/co abort if one item of svn:external resource list is not accessible

["C. Michael Pilato" <cm...@collab.net>]

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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand