On 6/7/07, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> One of the next things on my plate is to give users the option to
> resolve conflicts interactively. That is, rather than
> update/switch/merge just marking files as 'conflicted' and then
> letting the user deal with the conflicts later on, the whole process
> can optionally pause on a conflict and have the user interactively
> resolve the problem on the spot.
>
> I imagine that this interactivity would *not* be turned on by default,
> but by passing an argument like --accept={mine,theirs,...}... as in
> Jeremy's other patch ... that would be implemented as an extremely
> simple instance of the conflict-resolution callback. A more complex
> instance of the callback would actually prompt the user the way
> perforce does ("Do you want to use your version, their version, or the
> merged version?"). Furthermore, I imagine a new runtime config option
> could allow any arbitrary script or (GUI) program to do interactive
> resolution.
>
> My intuition is that the conflict-resolution callback interface would
> take file pointers as arguments -- pointers to our standard fulltext
> conflict files (including a merged working file that may contain
> conflict markers). The callback would return some specific enumerated
> value, much like Jeremy's svn_accept_t. The return values would be
> "use mine", "use theirs", "use the merged working file", and so on.
>
> Any thoughts/objections to my plan? Things I've forgotten?
I was with you until the last part. I think the "built-in" simple
acceptance callbacks shiould be more intelligent than operating on the
entire file. I think they ought to still merge the non-conflicting
hunks and only use this acceptance hint on the hunks that are in
conflict.
I think we should have a file-level callback for user-supplied
scripts/tools. Possibly we should have hunk-level callbacks too, but
I think we could defer that. Except for the built-in ones which I
think would be a good addition.
--
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 8 04:24:14 2007