Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> sussman@tigris.org wrote:
>
> > + - ? should the update interface also have the same API as above?
> > + It's not not necessary, since updates aren't atomic like commits.
> > + But it might be nice for consistency...
>
> An update of a single file (patch, merge, prop changes, metedata
> changes) *must* be atomic, or a flaky network connection will regularly
> corrupt the working copy. But that's all, I guess; apart from that, an
> update can be restarted.
Don't worry, it is. The working copy library is designed such that a
crash at any point will never leave your working copy in an
"incoherent" or unrecoverable state. When we update the working copy,
temporary copies are made and logfiles are written out. Then later on
the logs are `executed' and the temp files become the real files.
It's very much like a journaled filesystem.
What we're saying, however, is this:
* if I type `svn commit foo.c bar/ baz/ bop.h`
...and I get an error (say, an unresolved conflict) somewhere inside
baz/, then the *whole* commit aborts.
* if I type `svn update foo.c bar/ baz/ bop.h`
...and I get an error updating somewhere inside baz/, then foo.c and
bar/ are still updated. Their administrative areas are finished by
the time we get to baz/. Meanwhile, certain parts of baz/ will be
up-to-date, and certain parts won't. Either way, the working copy
isn't left in a broken state. When you next try to update baz/, a
cleanup process executes any remaining logs and/or re-runs the
update.
So: the working copy in *theory* should be uncorruptible. But when
talking about multiple command-line targets, only `svn commit` need be
atomic for the list of targets.
Received on Sat Oct 21 14:36:15 2006