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

Re: svn commit: r22496 - branches/multiple-moves/subversion/include

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2006-11-30 02:39:08 CET

Ed Price wrote:
> In log message for previous commit you wrote (more or less; emphasis
> added):
>
>> ***Improve*** atomicity in the case of wc->wc moves and copies.
>> Instead of performing existence checks on each item as we go,
>> perform them all up front. In this way, we catch errors before we
>> start performing any of the moves or copies, ***ensuring*** success
>> when we actually do the action.
>
> Hey! There is a big difference between *improving* vs *ensuring*
> atomicity.
>
> IIUC, you are *not* ensuring it, only improving the chances of it.
>
> Someone could still change the files (eg delete them) after your check
> and before the real operation. The computer could lose power halfway
> through the real copies. I don't *think* it is going to handle that
> case is it? The client is not built on a transactional filesystem
> like the server is...
>
> Anyway, this commit (r22496), saying that the operations are atomic in
> the docs, is therefore wrong. Please change it to say (if anything)
> "Some effort is made to be atomic" or whatever instead, because that's
> the truth. Don't say it *is* atomic, because it's not.

Ed,
Thanks for pointing this out. It's true that a wc->wc or repo->wc copy
won't be atomic, much like an update or a mkdir, isn't atomic. In fact,
the computer doesn't even have to lose power to prove such; the user
could simply cancel the operation mid-stride. repo->repo and wc->repo
operations are still atomic, of course, and use the facilities of the
server to assure such.

I'll update the documentation to reflect this.

-Hyrum

Received on Thu Nov 30 02:39:26 2006

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

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