But doesn't an interrupted update leave the WC in a dishonest state
too? The WC claims to match its former revision, but it's partway
through the update, and so its claim is a lie.
Also, what's the state of affairs if update is interrupted while
creating a new directory? What does that new directory's entries file
look like? Whatever it looks like, couldn't you just drop that in at
the top of a new checkout and then have checkout proceed as if it was
the resumption of an interrupted update?
Checkouts and updates would ideally be atomic. So, I assume what's happening
is:
1) Checkout/update starts. The WC (presumably entries) is marked as 'update
in progress'. The flag really only needs to be set for directory creation
and renames, because those are the cases that break the WC right now (by
leaving the entries file in a bad state). Other cases so far seem to be
caught by re-running update. OTOH, setting it in all cases is a good step
towards making things more atomic.
2) If the update is interrupted, all commands that rely on the WC should see
this flag and say:
Checkout/update in progress. Run 'svn update' to complete update.
Obvious candidates are info, add, rm, status, ren.
checkout and update would resume, and commit could work in theory as long as
adds/deletes/moves aren't done.
3) If resuming, use new report interface to figure out what is needed, then
get on with it.
4) Checkout/update ends. The flag is removed.
This sequence works for both checkouts and updates, leaves working copies in
a usable state, handles recursion elegantly (by setting the flag on each
newly created subdir), and increases the atomicity of the operation (can't
enforce it, but certainly encourages it).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:24:30 2006