On Sat, 2005-04-23 at 09:01, Philip Martin wrote:
> > Third, when a file is copied (not renamed), the original doesn't stop
> > being modified. It wouldn't make sense to propagate some of the
> > modifications (the ones that happened prior to the merge that involved
> > the copy operation, for instance). But we'd only get copyfrom
> > information in the one merge which encompasses the copy.
>
> Sure, you will sometimes get additional conflicts, but they are not
> hard to fix.
I'm not sure you're responding to my point directly here. I'm saying
that under your proposal, it would be easy to merge changes from the
original of a file to a copy on a first merge, but difficult to continue
doing so on subsequent merges because we wouldn't be able to simply use
copyfrom information to know when to propagate changes.
> Obviously there are scenarios for and against having local mods follow
> copies.
Let me give an example of how it might hurt the Subversion project.
Most of the files in libsvn_fs_fs are derived (with copyfrom
information) from BDB back end files. The actual situation is
complicated, but let's say they were simply copies of the BDB files.
Under your proposal as I understand it, every time we merged a change
from the trunk to a release branch, changes made on the trunk to the BDB
files would be auto-merged into the FSFS files. We would have to notice
this and revert the changes before committing the merge.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 18:05:03 2005