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