Re: Understanding move merge

Hi all,

I like this concept of move. It makes more sense to me. I think it
might interact in interesting ways with merge though... In particular,
in the same way there is a problem with only one half of a move being
committed, there might be a problem with only one half of a move being
merged.

The current copy and delete semantics make this well defined (if a
little weird). The proposed move semantics need to define what happens
during a merge when one end of a merge contains only one end of a move.
  I was thinking that it might just devolve to copy+delete semantics in
this case (or possibly error, but devolve with a -force tag?):

   - A file in the merge source (eg branch, when merging from branch to
trunk) was moved from somewhere else: It gets copied from the merge
source to the merge destination with history.
   - A file is no longer in the merge source as it has been moved
elsewhere: it is deleted from the merge destination (and maybe
conflicts if it has changed in the merge destination).
   - A file in the merge destination was moved from somewhere else: This
is treated the same as a new file having been added.
   - A file in the merge destination has been moved to somewhere else:
This is treated the same as the file having been deleted in the merge
destination (and maybe it conflicts if the file has changed in the
merge source).

I don't think you can get away with the same approach as commits where
you simply disallow such merges. You at least need to allow them with
'-force'.

Later,

Will :-}

On Wednesday, January 22, 2003, at 08:21 AM, Branko Čibej wrote:

 Philip Martin wrote:

 Branko Čibej brane@xbc.nu writes:

 This example is exactly why I keep saying that we should make svn
 mv
 an atomic operation that *does not* generate a new node in the
 filesystem. Then moves would become pure directory changes, and svn
 merge has to resolve those before merging the files themselves, like
 Philip said -- and so it would know before even starting the file
 merge
 that it found a rename.
[snip]
 Finally what about a commit of part of the rename

 $ svn mv zig/foo zag/foo
 $ svn ci zig

 I assume this has to be rejected by the filesystem/repository.

 Now here we're talking about client-side implementation issues. If that
 partial commit tells the file system to move zig, without a target,
 then obviously the repository will reject the commit.

 This partial-commit problem is in fact the main reason why I didn't
 change the behaviour of svn mv yet. The client must be able to detect
 this, which means that the working copy must record the fact that a
 file
 was moved (on /both/ sides of the move), and the commit editor must
 check that both sides of every move are included in the commit. It
 becomes obvious why we're doing a cp+rm now; the two halves of that
 operation can be committed separately, which makes the commit editor
 much, much simpler.

 With --force, we might possibly allow this case to degenerate from a
 move to a copy+delete; but by default, the client should error out when
 it detects a commit of a partial move like that.

 Luckily, an URL-URL move doesn't have this problem, and we don't allow
 moves between an URL and a WC anyway (and a good thing, too).

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org