On Wed, Jun 13, 2012 at 02:12:47PM +0200, Johan Corveleyn wrote:
> On Wed, Jun 13, 2012 at 12:20 PM, Justin Case
> <send_lotsa_spam_here_at_yahoo.com> wrote:
> > Why should I have to cleanup???
> > svn update (see point 2) KNEW the file is in use, so instead of leaving locks around it could just have skipped that file and print a message that not everything have been updated.
>
> The problem is that, at the point where svn runs into this locked
> file, half of the work has already been done (the metadata in wc.db
> has already been updated). The remaining work (moving the file into
> place) is scheduled in a specific table called the work_queue. The
> work_queue *must* be run to completion to get back into a valid state.
> It cannot be rolled back (undoing the other part in wc.db), at least
> not with the current design.
So, the awkward "external svn cleanup" requirement
is indeed "simply" a matter of implementation weakness in
"atomic transaction processing" (i.e. application of a collected change
only after *all* interim steps have been successfully completed in a
*temporary* working area,
or alternatively [when unable to implement it in such a definitely desireable way],
a properly working rollback mechanism for partially modified data).
> 'svn cleanup' removes any working copy locks, and runs whatever is
> left in the work_queue, thereby returning the working copy to a valid
> state.
Yeah, and ideally that currently running command itself would:
- either instantiate the modified dataset only after everything
has been successfully completed
(data modification could be carried out atomically
by an atomic rename of old dir vs. new dir or some such)
- or execute a properly working rollback mechanism
But as said before, that's possibly quite hard to achieve
in light of an existing possibly multi-layered implementation
which does things differently
(and which possibly has some existing binding contracts to userspace
which might get broken by a rewrite,
perhaps special wc.db behaviour or so).
Andreas Mohr
Received on 2012-06-13 14:49:35 CEST