On 6/8/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> On 6/8/07, Mark Phippard <markphip@gmail.com> wrote:
>
> > I was imagining the merge process could know that you said
> > --accept=mine and when it encounters a conflicting hunk it could just
> > apply the appropriate hunk and discard the other. No conflict would
> > need to be generated in this case.
>
> Yikes, do we really want to do that? That seems like a really
> dangerous and reckless behavior.
>
> I can understand someone saying, "just use my version", when they
> *know* the server's version should definitely be tossed away. Usually
> this happens when the two authors have had a conversation ahead of
> time, perhaps realizing they made the same changes, and deciding to go
> with just one person's version during the merge.
>
> But what you're suggesting above is that a user accept a version that
> is essentially a merged combination of two files, but that in the case
> of any conflicting hunks, automatically resolve the hunk conflict in
> one direction. This seems like a bad practice. If the file already
> has smooth merges in it, conflicting hunks probably need a human to
> examine in a case-by-case basis.
>
> Really, I think the whole idea of having a computer automatically
> choose a conflicting hunk *anytime* is fishy. Without a human
> intervening, it seems like a sure-fire way to end up with a file that
> doesn't even compile.
I was basing this on the sort of options that GUI merge clients tend
to provide. Granted in that case, someone has still somewhat looked
before doing it.
I guess I do not see the value in the whole file approach. That seems
even rarer to me. Eric Gillespie pointed out something like an
automated script that was doing merges for a release branch.
If you do not think hunk-based has value, and I do not think
file-based has value, maybe that is a sign that we do not need the
feature. Once Jeremy's patch is in someone can get your feature
pretty easily by running svn resolved after the merge.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 9 03:54:33 2007