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

RE: Re: Consistent revision when retrieving from repository

From: Douglas Stonham <dstonham_at_pennysaverusa.net>
Date: 2005-10-18 02:21:04 CEST

On Mon, October 17, 2005 3:43 pm, Stuart Celarier wrote:
> From Ben Collins-Sussman [1]:
>
> "If I run 'svn checkout URL', and somebody commits while I'm receiving
> the tree, do I get a half-broken tree, perhaps something buggy or
> unbuildable? Absolutely not. The checkout and update commands always
> grab exactly *one* revision tree, and revision trees are immutable
> objects. If you don't specify the revision with -r, then HEAD is
> converted to a single revision number at the beginning and that exact
> tree is fetched. Repository writers never interfere with repository
> readers. So here's at least one sense in which checkout is "atomic".
> You always get one specific tree, not a mix of trees.

This all seems to be a long winded way of trying to avoid saying that
updates are NOT atomic. Neither in SVN or TSVN.

Simple test: Do a large update and pull out the network cable half way
through... Chances are good that you will get an error message but it
will NOT roll-back the updates that had already been achieved...

So long as you are sure to re-issue the command once your network
connection is re-established, you will end up in the right place, but
until then, your WC is in a mixed revision state.

Not that I'm saying it's a bad thing, it means that if an update fails it
only has to pull what's left when it retries, but it certainly isn't
atomic.

Douglas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Oct 18 02:22:00 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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