Nicklas Norling wrote:
> I was asked on the TSVN list to ask about a behaviour Stefan King has
> reported earlier on
> IRC with Ben.
>
> It appears svn is not atomic on 'co' and 'up':
>
> http://svn.haxx.se/tsvn/archive-2004-12/0419.shtml
> http://svn.haxx.se/tsvn/archive-2004-12/0433.shtml
>
> Should this be registered as a bug maybe?
A short summary to the above (so you don't have to read the whole mail
threads):
When you do
svn up file1 file2 file3 file4
Subversion updates all files in the list to HEAD. The update is done on
each file individually. So if e.g. between the update of file2 and file3
someone else does a commit to the repository, file3 and file4 will not
be of the same revision as file1 and file2:
svn up file1 file2 file3 file4
at revision 100
at revision 100
-- now a commit happens
at revision 101
at revision 101
So to make sure that each file of such a multi-update is updated to the
same revision, TSVN first asks the repository what the HEAD revision is
and then updates all the files to that revision. If then a commit
happens, the update still will happen to the correct revision.
Also, to make sure that the files are actually from the same repository,
an 'svn st' is first done for each file to get the repository uuid - if
all files have the same uuid, then (and only then) the HEAD revision is
asked first. If they don't have all the same uuid, then TSVN falls back
to just updating to HEAD.
So I suggest that the CL client would do something similar. Or even
better, create an svn_client_update2() which takes a filelist instead of
just one file as the first parameter. Because that way the connection to
the repository could be reused.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 15 21:58:56 2004