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

Re: Understanding move merge

From: <philip_at_codematters.co.uk>
Date: 2003-01-21 23:00:44 CET

Branko Œibej brane@xbc.nu writes:

 The elimination of a new node is not always possible,
 $ 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.


 Does it involve storing a some sort of move flag in the
 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

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.