You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2005/02/27 22:30:36 UTC
Non-atomicity of svn_client_update2() [was: new functions in 1.2]
SteveKing wrote:
> svn_client_update2()
> --------------------
> "The paths in paths can be from multiple working copies from multiple
> repositories, but even if they all come from the same repository there
> is no guarantee that revision represented by svn_opt_revision_head will
> remain the same as each path is updated."
It would be good to remove that caveat. It's pretty horrible really.
> Why not just do what TSVN does now in such a case?
> - get the UID of the targets.
> - if all UID's are the same, fetch the HEAD revision
> - now update to that fetched HEAD revision (not HEAD but the specific
> revision).
I don't see much point in fixing just one case (all UIDs the same), even if
that is the most common case. We should fix it properly:
- Find all the different repositories of TARGETs.
- For each repository:
- Find the HEAD revision of that repository.
- Update all the TARGETs that are in that repository to that revision number.
Anyone fancy doing that (without making too many extra network round-trips)?
Are there other APIs that have a similar problem?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Non-atomicity of svn_client_update2() [was: new functions in
1.2]
Posted by Roel Harbers <ro...@roelharbers.nl>.
Julian Foad wrote:
> SteveKing wrote:
>
>> svn_client_update2()
>> --------------------
>> "The paths in paths can be from multiple working copies from multiple
>> repositories, but even if they all come from the same repository there
>> is no guarantee that revision represented by svn_opt_revision_head
>> will remain the same as each path is updated."
>
>
> It would be good to remove that caveat. It's pretty horrible really.
>
>> Why not just do what TSVN does now in such a case?
>> - get the UID of the targets.
>> - if all UID's are the same, fetch the HEAD revision
>> - now update to that fetched HEAD revision (not HEAD but the specific
>> revision).
>
>
> I don't see much point in fixing just one case (all UIDs the same), even
> if that is the most common case. We should fix it properly:
>
> - Find all the different repositories of TARGETs.
> - For each repository:
> - Find the HEAD revision of that repository.
> - Update all the TARGETs that are in that repository to that revision
> number.
>
> Anyone fancy doing that (without making too many extra network
> round-trips)?
>
> Are there other APIs that have a similar problem?
I don't know about the API, but from a user perspective, it would be
great if I could commit to several disjunct working copies from the same
repo in a single revision.
Roel Harbers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org