[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Atomic updates

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-11-23 16:47:26 CET

Erik Huelsmann wrote:
>>>You can do this today. Get the head revision number, then do an svn
>>>update -r <that rev>
>>>
>>>That's what I use when I want an "atomic" update (or checkout) that is
>>>done in several parts (several svn commands)
>>>
>>> paul
>>
>
>>Does it have any other advantage than guaranteeing that you will not
>>get a mix of files from different svn revnums because HEAD changed
>>while you performed the update in several steps?
>
>
> NO NO NO!!!!!
>
> Please don't suggest that's possible with Subversion! That's a problem
> with CVS which we have solved!
>
> If you run 'svn up' your working copy is updated to *the revision
> which is HEAD at the moment your update starts*. This means a new
> revision may become HEAD in the mean time, but the changes will not be
> sent to your working copy.
>
> In other words: If revision 3 is HEAD when you run svn up, if revision
> 4 is committed while you run your update, your working copy will be at
> revision 3 and *not* partly at revision 4.

You're right. Sorry.

I thought of updating 3 subdirectories only (one at a time) instead of
the whole WC but it seems that I can do 'svn up dir1 dir2 dir3', so it
can be done in one step - no need to do one at a time.

Now I don't see *any* advantage at all of specifying the svn revnum.
It clearly does not help in the case of an interrupt because of a
network failure.

Thanks for the clarification, Erik.

   Dirk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 23 16:53:19 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.