You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Becroft <Da...@supercorp.com.au> on 2008/01/10 09:01:06 UTC
SVN Update/Commit Concurrency
Hi all,
What is the method that SVN uses to control commits that happen during another user's update?
For example, in the following scenario:
1. [UserA] svn update (HEAD is 100).
2. [UserB] svn commit (HEAD is 101) - happens while UserA's update is happening
When UserA's update has completed, will the working copy revision number be 100, or 101? I'm guessing that the first thing that the 'svn update' would do is to get the HEAD revision and store that, so it becomes a 'svn update --revision 100' command?
I've attempted to replicate this situation without success - I can't seem to make UserA's update go long enough.
Cheers,
Daniel B.
Re: SVN Update/Commit Concurrency
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 10, 2008, at 03:01, Daniel Becroft wrote:
> What is the method that SVN uses to control commits that happen
> during another user's update?
>
> For example, in the following scenario:
>
> 1. [UserA] svn update (HEAD is 100).
> 2. [UserB] svn commit (HEAD is 101) - happens while UserA's
> update is happening
>
> When UserA's update has completed, will the working copy revision
> number be 100, or 101? I'm guessing that the first thing that the
> 'svn update' would do is to get the HEAD revision and store that,
> so it becomes a 'svn update --revision 100' command?
>
> I've attempted to replicate this situation without success - I
> can't seem to make UserA's update go long enough.
You are correct. The working copy will contain whatever revision was
HEAD at the time the update began.
The exception is externals. If your project uses externals that do
not specify an explicit revision, then they will be updated to
whatever revision was HEAD at the time each external is updated.
Commits may have occurred between the time the update began and the
time the externals are each updated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: SVN Update/Commit Concurrency
Posted by Daniel Becroft <Da...@supercorp.com.au>.
> -----Original Message-----
> From: Ulrich Eckhardt [mailto:eckhardt@satorlaser.com]
> Sent: Thursday, 10 January 2008 7:30 PM
> To: users@subversion.tigris.org
> Subject: Re: SVN Update/Commit Concurrency
>
>
> Note up front: I didn't actually look at the sources, so I
> might be wrong.
>
> On Thursday 10 January 2008, Daniel Becroft wrote:
> > What is the method that SVN uses to control commits that
> happen during
> > another user's update?
> >
> > For example, in the following scenario:
> >
> > 1. [UserA] svn update (HEAD is 100).
> > 2. [UserB] svn commit (HEAD is 101) - happens while
> UserA's update is
> > happening
> >
> > When UserA's update has completed, will the working copy
> revision number be
> > 100, or 101?
>
> It will be 100.
>
> > I'm guessing that the first thing that the 'svn update'
> would do is to get
> > the HEAD revision and store that, so it becomes a 'svn
> update --revision
> > 100' command?
>
> Right. The first thing is probably that it determines the
> head revision. From
> then on, even if the head revision changes, the revision
> itself doesn't (they
> are treated as almost immutable) so these changes don't
> affect the ongoing
> read operation.
>
> > I've attempted to replicate this situation without success
> - I can't seem
> > to make UserA's update go long enough.
>
> Throttle the network. ;)
>
> Just wondering, but what do you need this info for?
>
> Uli
THanks, Uli.
We are integrating SVN into our change management system. Each commit will schedule an update of the cross-reference information
that we keep. Now, because regenerating this x-ref information can take, potentially, between 30 minutes and 1 hour to complete over
the entire code base, we only want to do it on what has changed.
Now, the other problem that we had was that we have 'include' files, which are expanding at compile time (similar to C header file, I believe).
We use the previous X-ref run, and the changed file list, to determine which files actually need recompilation and scanning.
I just wanted to find out the above information before I went forward with the implementation. I wasn't sure if I was going to need to
implement a mutex to pause any commits whilst the x-ref's 'svn update' command is being executed or not. The answer is now, I don't.
Cheers,
Daniel B.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: SVN Update/Commit Concurrency
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Note up front: I didn't actually look at the sources, so I might be wrong.
On Thursday 10 January 2008, Daniel Becroft wrote:
> What is the method that SVN uses to control commits that happen during
> another user's update?
>
> For example, in the following scenario:
>
> 1. [UserA] svn update (HEAD is 100).
> 2. [UserB] svn commit (HEAD is 101) - happens while UserA's update is
> happening
>
> When UserA's update has completed, will the working copy revision number be
> 100, or 101?
It will be 100.
> I'm guessing that the first thing that the 'svn update' would do is to get
> the HEAD revision and store that, so it becomes a 'svn update --revision
> 100' command?
Right. The first thing is probably that it determines the head revision. From
then on, even if the head revision changes, the revision itself doesn't (they
are treated as almost immutable) so these changes don't affect the ongoing
read operation.
> I've attempted to replicate this situation without success - I can't seem
> to make UserA's update go long enough.
Throttle the network. ;)
Just wondering, but what do you need this info for?
Uli
--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Michael Wöhrmann, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org