On Mon, 2004-04-05 at 06:43, Folker Schamel wrote:
> > 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.
Propagating a merged change to all copies of a file would be a distinct
case of the version control tool being too clever. If foo has been
copied to bar in order to create a branch of foo, then it's up to the
user to propagate the bugfix or not depending on the nature of the
branch. If foo has been copied to bar in order to create a different
but derived implementation (e.g. ra_svn's editor.c being copied to
editorp.c), then a change to the original may or may not make sense for
the copy.
Just because you can imagine one scenario where it's a good idea to do
something clever and complicated doesn't mean it's a good idea to
implement the clever and complicated feature.
> 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".
The fundamental reason to copy a file rather than create a new one is to
preserve history, not to create some kind of Byzantine automated change
propagation network.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 5 19:16:51 2004