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

RE: Issue 730 related question about svn_ra_reporter_t interface

From: <John_Barstow_at_gfsg.co.nz>
Date: 2003-01-29 23:59:03 CET

 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

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