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
repositories.
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.
Regards,
Blair
--
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion and Orca training and consulting
http://www.orcaware.com/svn/
---------------------------------------------------------------------
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