> Here's the problem: you asked 'svn merge' to merge in the differences
> between two versions of joes-branch. And it did exactly that; that
> difference was a rename (delete + add). But joe never merged in
> *your* change to the file before he did the rename!
> The only way to prevent this is to have joe and bob coordinate their
> branches better.
Supposing rename was a primitive operation, then, theoretically, you
could keep "the pathname of the file" separate from "the contents
of the file" and parallel rename+merge would Just Work (tm). There
are implementation problems with this approach, but I'm not aware
of any that are insurmountable. Daytime, I'm actually using something
like this (but not exactly) in Perforce by judicious use of client-
spec file path re-writing. It is very useful.
However, if you treat rename as "delete+add" or as "copy+delete"
then you can't really do this.
I went through the various hacking/readmes and the issue tracker,
and couldn't find any issue documenting a feature request that
renames be handled as a primitive operation (instead of being
simulated with two operations). Is this already on the plate, or
should I file an issue about it? The description in "goals" seems
to imply that this is the implementation necessary in the end, but
I'm confused about not seeing it mentioned anywhere else.
Cheers,
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 11 00:13:25 2002