> 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.
As for every normal modified file in the branch, too:
A merge may or may not make sense.
> 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.
It's not only "one scenario", its the standard case:
If a file has the history of another file,
this means per definition that it has the same content
plus modifications, and merging is necessary
in the same way as for normal modified files.
(But of course, in a particular case a merge may be not
senseful or may fail in both cases if you have overlapping
non-orthogonal changes).
But if the content of the copied file is fundametally different
from its original, it makes no sense to talk about / keep the history,
and it should be treated as new file.
If you say that because of implementation issues
this is too complicated, then the right solution is
to support moves, but no copies at all.
Copy with history but without merge support makes no sense.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 6 03:40:12 2004