Re: svn merge on branches containing moved files/directories

Ben Collins-Sussman <sussman@collab.net> wrote:

> So no, you're not crazy. Your situation with 'svn merge' is just
> another variant on this. When you 'svn merge' your
> directory-reorganization branch to a different place, you're not
> getting 'moves' of what happens to be there already. You're getting a
> bunch of deletes and adds of older things.
>
> This is why, after we finish locking, that "true moves" are the next
> big item we want to fix.

Ben, I think that "true moves" are only a partial solution to this
problem.

We are working with a development model where virtually no work is done
on the trunk; all development takes place on branches. If a task is
done, the branch is merged to the trunk and deleted.

Now consider the case where a developer works on file A in his branch;
he decides that A has become too large, so he splits it in three new
files A1, A2, and A3, then he deletes A. (No move involved.)

Meanwhile, another developer makes changes to A in *his* branch. Later,
when both branches are merged to the trunk, the second developer's
changes to file A will be lost, silently.

I think this is a huge problem that needs addressing.

We have the feeling that the problem can be solved by introducing the
concept of "directory conflicts". (I'm not talking about textual
conflict markers here, but about the "C" that you see in svn status.)
If a merge brings in a change for a file that has been deleted in the
target, the containing directory should be marked as conflicting
(instead of, or in addition to, the "skipped missing target" message
that you now get during the merge); conversely, if a merge would cause a
file to be deleted that has a higher revision number in the target than
the revision where the file was deleted in the source, there should be a
conflict too. This is the case where you now lose data completely
silently, which is evil.

Until Subversion supports something like this, we are now having two
problems:

1) How can we find out whether we might have lost changes in the past?
   We are thinking about writing a script that parses svn -v log output,
   somehow checking that deleted files are not modified in another
   branch at a higher revision or something. I'm not yet clear about
   the exact algorithm needed here.

2) How can we make sure that this problem doesn't occur in the future?
   Again, we are thinking about an automated solution, something like
   remembering all deleted files in a database, and having a pre-commit
   hook check that no modifications are committed to a file that was
   deleted in another branch.

This is all very preliminary yet, I was just wondering if anybody has
already thought about these issues and have any ideas about the matter.

-- 
Stefan Haller
Ableton
http://www.ableton.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org