On Fri, 08 Jun 2007, Mark Phippard wrote:
> 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.
Not if you accept your local mods. Then, you haven't dropped any
changes which aren't under version control.
> >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.
This is actually a very common use case that I've heard from corporate
development shops. This can't be discounted.
> 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.
'svn resolved --accept=mine' is a potential work-around for this use
case, but is not likely to be accepted without a good deal of
grumbling (at best).
- application/pgp-signature attachment: stored
Received on Mon Jun 11 21:28:19 2007