[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: <naked_at_iki.fi>
Date: 2003-01-30 00:39:34 CET

John Barstow wrote:
 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:


 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).

This is not needed - updates are not atomic, but they are continuable
(if we ignore the recent bug, that's only a simple bug).

Let's make an example - a simple one, without directories, for
clarity's sake. Ok, we have directory 'A', and currently three
children in it - 'alpha', 'beta', 'gamma' - all at revision 3:

 3 A/
 3 A/alpha
 3 A/beta
 3 A/gamma

Now, assume a subsequent commit (revision 4 in the repository),
modifies all files, and adds a new child, 'delta'. Now, when we run
'svn up', first we tell the server that we have revision 3 of path
'A', and that everything inside it is the same revision too. Then, the
server starts sending changes, and opens directory 'A', and proceeds
with sending changes. But when it has gotten past 'beta', we interrupt
it. What we have now is:

 3 A/
 4 A/alpha
 4 A/beta
 3 A/gamma

The reason directory 'A' is still revision 3, is that the revision
number isn't updated until after the directory is closed - that is,
until all changes have been transmitted in it. Now, when we run 'svn
up' again, it first tells the server that we have revision 3 of path
'A', and that paths 'A/alpha' and 'A/beta' are revision 4. The server
then again opens directory A, and continues to send changes, but
doesn't send the changes for 'alpha' and 'beta', since it has been
told that we have them already. Now, we let the update finish - and
end up with:

 4 A/
 4 A/alpha
 4 A/beta
 4 A/gamma
 4 A/delta

Everything is clean, nothing needs to be locked for atomicity - and
updates need not necessarily be continued - we could say 'svn up -r 3'
and it would remove the changes in 'alpha' and 'beta' and bring them
back to revision 3.

So, there's nothing fundamentally wrong with this, just some edge
cases again.

-- Naked

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:34 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.