Greg Hudson <ghudson@MIT.EDU> writes:
> On Fri, 2005-04-22 at 20:59, Philip Martin wrote:
>> I guess it depends what one means by "good". Update could make better
>> use of copyfrom information to move local mods within a working copy,
>> I suspect merge could do the same. If merge and update were to do
>> that then we might be able to handle tree reorganizations in a manner
>> that is "good enough" in most cases.
>
> I really think this idea doesn't lead anywhere fruitful.
>
> First, there can be more than one copy of a file. Propagating a local
> modification from one place to many places could create a huge mess.
A mess that is easy to resolve with revert. With the bonus that when
the copy is part of a mv=cp+rm it is likely to do exactly the right
thing without any mess.
> Second, we generally don't have a good idea of why a file was copied.
> It could be for a rename, it could be to create a branch, it could be
> because the original was a template. So unlike the usual case of
> merging modifications made to a file which doesn't move, we don't have a
> very sound basis for assuming modifications should be propagated.
I'm not sure I follow that argument, but I would point out that branch
creation doesn't usually involve local mods.
> 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. A really smart client might be able to retrieve
additional history information and do a 4-way merge, but I suspect
that's overkill.
> You're not the first person to suggest that copy operations should
> create a network of automated change-propagation. But I think it would
> wind up being perceived by users as spaghetti.
Obviously there are scenarios for and against having local mods follow
copies.
I agree that if local mods follow copies then there will be more
conflicts, but those are easy to handle: they show up in status and
can be fixed by revert. That's a much better failure mode than the
alternative: the wrong file is in conflict and there is no clue
as to which other file should be changed.
Consider a file foo.c that has grown too big and is to be split, with
the "ziggy" bits going into zig.c and the "zaggy" bits into zag.c. It
could be done like this:
$ svn cp foo.c zig.c
$ svn mv foo.c zag.c
$ vi zig.c zag.c
$ svn ci
or like this:
$ svn cp foo.c zag.c
$ svn mv foo.c zig.c
$ vi zig.c zag.c
$ svn ci
The person making the change doesn't really care which is chosen, but
in another working copy, one with local mods to foo.c, it matters a
great deal. If the local mods follow the move into the wrong file
they will likely generate a conflict. The usual conflict resolution
tools won't work properly because the "correct" destination is a
different file, namely the copied file. Nothing in the update
feedback or the working copy state connects the copied file to the
original.
I'm not claiming that we have to make local mods follow copy
operations, the system will work without that, but I am not convinced
that mods following copies is a bad idea. Given that it also fixes
mv=cp+rm I think it deserves to be considered as an alternative to
"atomic rename".
--
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 15:02:15 2005