Branko ÄŒibej brane@xbc.nu writes:
The elimination of a new node is not always possible,
consider
$ svn mv zig/foo zig/bar
$ echo stuff zig/bar
$ svn ci zig
Of course it's not possible to eliminate a new node in this case. That's
because your example isn't a move, it's a move+modify.
Move+modify is quite common, e.g. rename foo.[ch] to svn_foo.[ch] and
then modify svn_foo.c to #include svn_foo.h instead of foo.h. One
would not want to have to commit the plain move, that revision would
not compile.
[snip]
Does it involve storing a some sort of move flag in the
repository?
No, not at all. What you get is simply a change in one or two
directories' entries.
I'll try to illustrate the point. Imagine you have two directories A
and B, that are children of the root. A contains the files foo and
bar, B contains qux. I'll tag each node with its node revision number:
/ (0.0.4)
A/ (a.0.3)
foo (f.0.2)
bar (r.0.3)
B/ (b.0.4)
qux (q.0.4)
Now see what happens when we svn rename /A/foo /B/baz:
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.0.2)
qux (q.0.4)
We created new revisions of A, B and / (because of bubble-up), and
the pointer to f.0.2 is now called baz rather than foo, but the
node itself did not change, and its immediate ancestor is still the
same, although you can't guess that ancestor's name from the current one
(note that the repository does know that name already). So we don't need
any new flags in the repository at all.
So in the move+modify case, where a new node needs to be created, I
suppose it would look like
/ (0.0.5)
A/ (a.0.5)
bar (r.0.3)
B/ (b.0.5)
baz (f.1.5)
qux (q.0.4)
Will this be a problem? Does it mean that the client will be unable
to distinguish copy+delete from move+modify?
It would appear that atomic move has potential benefits, the client
will be able to perform better if it can identify a move. It would be
a shame if that improvement did not apply to move+modify. I like the
idea of atomic move, I'm just worried that it is not complete.
--
Philip Martin
---------------------------------------------------------------------
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:05:14 2006