Re: Understanding move merge

Philip Martin philip@codematters.co.uk writes:

  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)

Perhaps baz (f.0.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?

Then it would be distinct from copy :) Yes, that does look more like
what we want.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org