> From: Colin Putney [mailto:colin@whistler.com]
>
> Philip Martin <philip@codematters.co.uk> wrote:
>
> > > 3. If the wc file has been modified or the --force option is used,
the
> > > backup fulltexts are deleted.
> >
> > When does this "has been modified" check occur? Does it occur at
the
> > 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
used
> > 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
resolve
> > 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
only
> be reached if steps 1 and 2 were not executed. That is, if no merge
tool
> 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
run.
> 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
the
> one stored in the entries database to see if the file has been
modified.
> If so, or if user insists on committing a file with conflict markers
via
> the --force option, the conflict fulltexts are removed and a commit
can
> 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
way.
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
use.
>
> On Sunday, March 17, 2002, at 02:11 PM, Karl Fogel wrote:
>
> > Colin Putney <cputney@whistler.net> 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,
which
> > 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.
The
> > 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
anything.
Here are the two suggested forms of "svn resolve":
"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.
Bill
Perforce command reference:
http://www.perforce.com/perforce/doc.011/manuals/cmdref/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 19:18:30 2002