> From: Zack Weinberg [mailto:zack@codesourcery.com]
> On Fri, Mar 15, 2002 at 12:11:19PM -0800, Colin Putney wrote:
> >
> > I'd like to see this sequence of checks happen for svn resolve.
> >
> > 1. If there's a merge tool configured for the conflicted file, it
gets
> > launched with the wc file and the three conflict fulltexts as
> > parameters. When it exits, the conflict fulltexts are deleted and
the
> > conflict is resolved.
> >
> > 2. If there's no merge tool and the file is not a binary file, the
> > user's $EDITOR gets launched with the wc file (which has conflict
> > markers) as it's target. When it exits, the conflict fulltexts are
> > deleted.
> >
> > 3. If the wc file has been modified or the --force option is used,
the
> > backup fulltexts are deleted.
> >
> > 4. If none of the above conditions are met, svn resolve errors out
> > because the conflict wasn't resolved.
>
All of this discussion stems from talking about how the svn command line
should work. Let's back up a bit for a second or two though.
The WC needs to be manually told when conflicts are resolved. It
requires this information so that a commit of the formally conflicted
file will now succeed.
The user needs to manually tell the WC that the conflict has been
resolved.
Whether that happens through some merge tool, or some other mechanism I
don't really care. Someone, either the merge UI tool, or the user needs
to manually inform the WC that the conflict has been resolved.
Just invoking the user's $EDITOR and checking for a modified timestamp
isn't good enough for a variety of reasons:
* The user may have not actually finished resolving the conflict.
* The user might have accidentally saved and exited the editor too soon.
* We can't write code to check for conflict markers, it's just not
feasible. People might actually want to check in conflict markers. (aka
Karl's book on CVS)
Therefore, in order to prevent accidental merge conflicts from getting
submitted we need a manual mechanism to tell the WC that we've resolved
our conflict. "svn resolve" is our current name for this mechanism.
So, let me propose a modified version of the algorithm and see what you
think:
1. If there's a merge tool configured for the conflicted file, it gets
launched with the wc file and the three conflict fulltexts as
parameters. The merge tool MUST return enough information to "svn
resolve" to tell us whether or not the conflicts were indicated
successfully resolved or not. If they were not successfully resolved, we
print a helpful reminder error message and exit.
2. Tell the WC that the conflict has been resolved, and let the WC get
about figuring out what it needs to do. (i.e. delete those three files)
The recursive version of "svn resolve" would skip step #2. Each file
needs to be manually visited and manually resolved. Beginning to see why
merge UIs are so useful yet? :)
Now we just need a spec for how you categorize input files so that you
know which merge tool to run. How does the following sound for a decent
start?
The idea here is that the following checks would be performed in the
order listed:
* Files based on a file pattern. (i.e. *.doc, *.xml, etc...)
* Text files invoking your standard text file 3-way merge resolution UI.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 15 22:10:07 2002