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
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
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
On Wednesday, January 22, 2003, at 08:21 AM, Branko Čibej wrote:
Philip Martin wrote:
Branko Čibej firstname.lastname@example.org writes:
This example is exactly why I keep saying that we should make svn
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
that it found a rename.
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
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
Email: email@example.com University of New South Wales
Jabber: firstname.lastname@example.org Sydney, Australia
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 14 02:06:05 2006