Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
Perhaps I did get a bit sidetracked, I started by asking why so many
people wanted "atomic rename" and I think it's because they want local
modifications in a working copy to get moved when an update moves the
modified file. At present update causes such modifications to become
unversioned. Fixing that problem doesn't require "atomic rename", it
could be done by having the local modifications copied from the
modified file to the new file when a new file gets added with copyfrom
history. I thought you were claiming that such an update scheme would
not work. I wasn't really discussing merge tracking.
>> 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.
I wasn't suggesting that, at least I didn't intend to suggest that,
I'm not sure I even understand it.
What I would suggest is that if merge causes a locally modified file
to get copied, i.e. the merge adds a file with a copyfrom history that
can be interpreted as a locally modified file, then that local
modification could get applied to the newly added file. That's a one
off, subsequent merges won't add the file again as it already exists,
so no further copying of local modifications would occur. I don't
know how useful such merge behaviour would be, in the case where the
merge also deletes the locally modified file then it's might well be a
good thing as it would avoid the problem of the local modifications
becoming unversioned.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 23 19:20:58 2005