The "follow copy history" initiative

From: Greg Hudson <ghudson@MIT.EDU>:

> Imagine for a moment that we had really good merge support. Say I want
> to perform the following merge:
>
> BASELINE: contains file "foo"
> MAINLINE: copies "foo" to "bar"; renames "foo" to "baz"
> BRANCH: modifies file "foo"
>
> The best merge result we can expect from a version control tool has the
> branch's modifications to "foo" merged into "baz", with "bar"
> unchanged. To get this result, we have to distinguish the rename from
> the copy.
>

I think this is not correct.

Suppose for example the modification of "foo" in BRANCH
are a bug fix, then the bug should (must?) be fixed BOTH
in "bar" and "baz".
Because - except in case of an overlapping modification -
both files contain the bug.

If "bar" would be fundamentally different from "foo",
so that bug fixes of "foo" are never relevant for "bar",
then "bar" should be added as new file and not as copy of "foo".

Folker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 12:44:31 2004