> From: Colin Putney [mailto:email@example.com]
> Philip Martin <firstname.lastname@example.org> wrote:
> > > 3. If the wc file has been modified or the --force option is used,
> > > backup fulltexts are deleted.
> > When does this "has been modified" check occur? Does it occur at
> > point at which the resolve command is invoked, comparing the wc
> > against text-base? At present the wc file will always be modified,
> > that's the only way a conflict can occur. (Other conflict
> > possibilities may arise when 'svn merge' appears.)
> > Or does it mean comparing the wc before and after invoking the merge
> > tool? If so, I think the exit status of the merge tool should be
> > instead. Even if I have changed the wc, if I abort my merge tool I
> > don't want files deleted. And for binary files I may decide to
> > the conflict by making no changes to the wc, again I would want the
> > merge tool's exit status to determine whether files get deleted.
> The numbered steps in my proposal were a kind of search algorithm for
> deciding how to handle the svn resolve command. So step three would
> be reached if steps 1 and 2 were not executed. That is, if no merge
> were found and $EDITOR was not invoked, either because no editor was
> configured or because the file was binary.
> I meant for the modified check to occur when the resolve command is
> The it would determine whether the file has been modified since it was
> marked conflicted. I like the idea (but I forget who proposed it) of
> using a digest for detecting this.
> So 'svn update' would notice the conflict, create the conflict
> fulltexts, add conflict markers to the wc copy of the file (if it's a
> text file) and compute a digest of the wc copy and store it in the
> entries database.
> Step 3 of my algorithm recomputes the digest and compares it against
> one stored in the entries database to see if the file has been
> If so, or if user insists on committing a file with conflict markers
> the --force option, the conflict fulltexts are removed and a commit
> be made.
No, no, no. All of this heuristic checking is complicating the issue.
The user must manually resolve all conflict issues in a user visible
Either through the merge tool, or through manually typing the file name
as an argument to "svn resolve". This modification checking just
complicates things and opens up doors for sloppy developers to submit
something they shouldn't.
A merge tool is the only option that would actually make this easier to
> On Sunday, March 17, 2002, at 02:11 PM, Karl Fogel wrote:
> > Colin Putney <email@example.com> writes:
> >> It's counter-intuitive to have a command with such an
> >> important-looking name that doesn't do anything but save you a few
> >> keystrokes.
> > Another option is to change the name, then... :-)
> > Instead of "svn resolve" (which sounds like it resolves something),
> > maybe "svn resolved". That sounds like something got resolved,
> > is what the user is trying to indicate.
> > I'm all for automatically invoking a merge tool, and possibly using
> > its exit status to determine whether or not to change the conflict
> > state, but there still needs to be a way to tell Subversion
> > (independently of any other tool) that the conflict is resolved.
> > two features are separate. We chose a bad name for the simpler
> > feature, so let's just use a different name.
I'd actually disagree with Karl here. I don't think we need to rename
Here are the two suggested forms of "svn resolve":
Here svn should go and loop over all conflicted files and running them
through the merge tool if possible, and reporting error messages for all
files that can't be so merged.
This makes sense because "resolve" is a verb, and the direct object is
implied as anything that can be resolved via the merge tool.
"svn resolve <file>"
This manually resolves the listed files conflict status.
This also makes sense because the direct object of "resolve" is
explicitly specified. (i.e. the file)
What is misleading here?
Any of the above forms of "svn resolve" transitions the working copy
file state of its direct object(s) from "conflicted" to "resolved" (and
thus available for commiting).
Any "svn resolved" command would tend to imply (as it does for Perforce)
that you should print out all files that have been successfully resolved
and waiting for a "svn commit" to be submitted back to the repository.
Perforce command reference:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Mar 18 19:18:30 2002