On 6/1/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> "Mark Phippard" <markphip@gmail.com> writes:
>
> > This leads me to wonder if that is not what should be happening here
> > as well. If the files are unmergeable (binary) it would do what it is
> > doing now. But if these are text files, it seems like it ought to
> > merge them and use this setting to resolve the conflicts it encounters
> > along the way.
> >
> > Thoughts? Am I out of my mind?
>
> I've proposed this feature in a couple different forms over the
> years ;->. The most recent proposal was inspired by Perforce's
> -am, -ay, and -at options: --accept={merged,yours,theirs} . And,
> all i was looking for is what Jeremy has implemented. That's
> also all Perforce implements.
>
> Now, if it's possible for us to do even better, and do this at
> the individual patch hunk level, even better! I think that is a
> much bigger chunk of work, though.
We discussed a bit on IRC. I'd say the conclusion was that the
current approach is good for resolved command, but for the others, it
would need to be a hunk-based approached where this option only
applied to the hunks that were in conflict. Here is a transcript:
dlr_h: markphip: I didn't really see a problem WRT the command-line.
dlr_h: It's definitely an issue for UIs with potential for more
involved merging interfaces.
markphip: so you would be in favor of implementing this as-is for
commands like merge/up/sw?
dlr_h: ...where a merge conflict resolution callback would be in order.
dlr_h: --accept would "conflict" with a merge conflict resolution callback, no?
markphip: I assume a callback would take precedence
markphip: I just do not think the --accept option in this form makes
sense for those other commands
dlr_h: For a command-line merge conflict resolution mode, the accept
logic would need to be extended to the chunk level.
dlr_h: And, include an option like "edit".
markphip: right, that is all I meant
*pburba thinks we should elide these options
markphip: It couldn't let the merge process create the three files,
and then select one of them and resolve it, like svn resolved does
markphip: except for binaries
dlr_h: even binaries might someday have a "smart resolution" mode,
with a merge tool which understands their format
markphip: I think what Jeremy did is OK for resolved
dlr_h: me too
markphip: I think the other commands need to merge what they can, and
as you say, this could be like a built-in callback to select one of
the revisions when there are conflicts
markphip: favor might be a better term than select here
dlr_h: favor implies you still might not choose it
dlr_h: you might want to summarize this discussion in a follow-up email
--
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 Fri Jun 1 21:22:52 2007