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

Re: Are Updates and Checkouts also atomic?

From: Blair Zajac <blair_at_orcaware.com>
Date: 2005-05-19 21:53:48 CEST

Noah Spurrier wrote:
> After I perform an "svn update" am I guaranteed
> that every file in my local workspace all have
> the same revision as the remote repository?
> (Note, I understand that COMMITS are atomic.
> This is a different question.)

Yes. If you are checking out or updating and a commit takes place
during the checkout or update, your entire working copy will be at the
revision that was selected at the beginning of the update or checkout.

> We are considering using Subversion as a way
> to distribute sets of files to clients.
> The sets of files must all be updated to match
> the repository or not at all. If the client
> looses connection during an "svn update" operation
> we want to be sure that the client does not have
> some files from the current revision and some file
> from the previous revision.

You will end up with a mixed revision working copy.

> As far as I can tell Subversion uses transactions on
> the server-side for updates, but this seems to be
> used for locking the database to build diffs before
> sending them down to the client.
> It is not clear that updates are
> an "all or nothing" operation on the client side.
> If this is not the case, then it wouldn't be too hard
> for us to wrap this feature around svn, but it would be nice
> if we got this for free from Subversion.
> Another idea would be to have the clients all run
> Subversion servers with copies of the repository.
> So to update the clients we would do an "svn commit" operation;
> then have the client "svn update" from localhost. We can accept
> the risk of assuming that "svn update" from localhost would never fail.
> This process seems a bit convoluted.

You would use something like svk then for this to have multiple

Another possibility is to have the client have a staging working copy
which, when successfully updated, is then rsynced out to other client
systems. The rsync doesn't happen until the working copy as at a single
revision, which you can test with using svnversion.

This is probably cleaner, as having a repository at the clients site
that clients may accidently commit to doesn't sound like a good idea.


Blair Zajac, Ph.D.
Subversion and Orca training and consulting
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 19 21:55:34 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.