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?
---------------------------------------------------------------------
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:07:58 2007