You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicklas Norling <ex...@exinor.net> on 2004/12/15 20:06:58 UTC
Atomicity issue on co/up?
Hi.
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?
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Atomicity issue on co/up?
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 15 Dec 2004, Stefan wrote:
> Peter N. Lundblad wrote:
> > On Wed, 15 Dec 2004, Stefan wrote:
> >
> >
> >>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.
> >>
> >
> > I think most client commands should take a targets array instead of a
> > single target. But we have to consider the case where the targets are in
> > different repositories or working copies.
>
> As I mentioned: TSVN compares the repository uuids which you can get by
> doing an svn_client_status() - if the uuids match, then the targets are
> from the same repository.
>
Yes. I just wanted to mention that it will make things more complicated if
we do such a switch more generally. For the update case, you'd need to
group the targets per repository I suppose.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Atomicity issue on co/up?
Posted by Stefan <st...@gmx.ch>.
Peter N. Lundblad wrote:
> On Wed, 15 Dec 2004, Stefan wrote:
>
>
>>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.
>>
>
> I think most client commands should take a targets array instead of a
> single target. But we have to consider the case where the targets are in
> different repositories or working copies.
As I mentioned: TSVN compares the repository uuids which you can get by
doing an svn_client_status() - if the uuids match, then the targets are
from the same repository.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Atomicity issue on co/up?
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 15 Dec 2004, Stefan wrote:
> 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.
>
I think most client commands should take a targets array instead of a
single target. But we have to consider the case where the targets are in
different repositories or working copies.
For example, the new svn_client_lock (on the locking branch) takes a
single target (at the moment). I did it that way for consistency, but the
problem is that if you lock 10 files, it will open/lock the WC 10 times
and open ten RA sessions. Not very efficient.
Don't know what others think.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Atomicity issue on co/up?
Posted by Stefan <st...@gmx.ch>.
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