Gale, David wrote:
> Scott Palmer wrote:
>
> The problem is, both positions have valid work examples. If there's a
But again, that's true of ordinary conflicts, even though the latter can be more
complicated. There are conflicts where the correct result is to keep the
current code and throwing away the change from the branch being merged into the
working copy. Likewise, there are conflicts where throwing away the change in
the current copy and keeping merged in from the branch is the correct thing to
do. The one difference is that in the case of ordinary conflicts, keeping both
(with or without additional edits) is an option while it's not here.
I suspect it's the lack of that third option that's misleading people into
thinking this case is different. It's not. A conflict occurs any time two
different branches change the same line of code, even if the change to that line
is via deleting the containing the file.
...>
> In general, I tend to think that the current behavior is more likely
> than not to "do the right thing" by discarding no-longer-needed changes,
> and the (presumably rare) instances where the changes are, in fact,
> needed, should be caught by the person doing the merge (anyone who
> commits any changes without testing should be taken out and shot; merges
> are typically big changes, so failing to test after a merge should
> require a sufficiently big gun).
Yet if a merge is a really big change, requiring a full test of the system, it
may not be possible for an individual developer to run those tests, due to lack
of resources. Compile, sure, but not all errors, even in this case, will be
found at compile time. For that matter, it's also possible that the changes in
this case are to the tests, in which case the lossage may not be found for
months or years. (Say one person deletes a set of test cases since none of them
are useful, while a second adds a test case or a change that makes them useful.
How do you tell when you've lost a test case?)
> Throwing a warning might be nice, but
> I think it ought to be only a warning, not a conflict.
In this context, a conflict is nothing more than a warning that requires an
additional step to resolve. This makes me wonder whether the behavior should be
a configurable option.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 10 01:27:16 2006