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.
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.
Perhaps the thing to do is reverse the priorities I proposed, and only
launch a merge tool if the file is unmodified since it was marked
conflicted. Either way the intent is to have the resolve command to the
resolution if possible, error out if not, and mark conflict resolved if
resolution was successful or unnecessary (that is, already accomplished
by the user).
I admit that there's a slight semantic clash between the command name
'resolve' and the case where the user resolves the conflict manually and
then runs 'svn resolve' to indicate this in the working copy meta-data.
But I think that's preferable to either an essentially empty command or
two similarly-named-but-semantically-different commands.
-Colin
Colin Putney www.whistler.com
Information Systems (877) 932-0606
Whistler.com (604) 935-0035 x221
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 18 02:47:26 2002