Re: Are Updates and Checkouts also atomic?

Noah Spurrier wrote:
> -----Original Message-----
>
>>From: Michael Melanson [mailto:michael@interglobal.ca]
>>Sent: Thursday, May 19, 2005 12:54 PM
>>To: Noah Spurrier
>>Subject: RE: Are Updates and Checkouts also atomic?
>>Have you considered using rsync? It's designed for purposes like what you
>>just described.
>>--
>>Michael Melanson
>>.NET Programmer, InterGlobal Solutions
>>michael@interglobal.ca
>
>
> But rsync isn't atomic (at least, I don't think so).
> If you rsync a bunch of files and kill the
> connection after half the files have been
> copied you will end up with half the files
> updated and half in the old state... I know
> it's atomic PER FILE, but not atomic over
> a set of files.
>
> I could be wrong. We did consider rsync.
> We thought of building a tar-ball; rsyncing that;
> then opening the tar-ball on the client side.
> Rsync would make sure that the transfer is atomic.
> The disadvantage is that you would almost
> always have to transmit the entire tar-ball even
> if only a few files change. I know rsync
> is supposed to do some sort of binary diff
> to help with this, but my experience has
> been that this isn't very effective.
> Hmm... now that I think about this again I think
> maybe I should test this more. It is highly likely
> that my low opinion of rsync binary diff is
> due to my experience with rsyncing compressed
> binaries where small changes in the original
> file usually yield very different compressed
> output files -- thus causing rsync to copy
> the entire file... A tar-ball does not have
> to be compressed. Small changes in files in a
> set will probably yield similar tar files.
>
> Often times after restating the problem
> you realize you are trying to solve the wrong problem.

If you truely need an atomic update, then I don't think you'll find any
tool that will update your entire working copy all at once. There will
be a time that it'll be mixed revision.

Your only hope is to do something like

1) Copy your existing working copy.
2) Repeatdly upate the new working copy until it is entirely up to date.
3) Rename the now older working copy out of the way and move the new
working copy into its place.
4) Delete old working copy.

This makes the copy at the client's end, wasting disk space and disk IO
to save bandwidth.

If you don't need this level of updating, then my point was that,
hopefull at some point of the client's network infrastructure, you could
trust the connection. You may not trust an rsync from the client to
your network, but maybe you can trust an rsync entirely on the client's
network, hence have a staging working copy at the client.
a brand new checkout in another directory

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