You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Zack Weinberg <za...@codesourcery.com> on 2002/03/15 18:58:08 UTC
svn resolve: just what does it do?
I'm a little confused by the "svn resolve" operation which has been
described in some messages to this list. It sounds like all it does
is delete the conflict-marker files, after the user has fixed up the
file under conflict by hand.
I think users are more likely to expect that "svn resolve" invokes
some sort of interactive conflict resolution utility. That's what
Perforce and Bitkeeper both do with that subcommand.
Am I totally off the wall here?
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn resolve: just what does it do?
Posted by Colin Putney <cp...@whistler.net>.
On Friday, March 15, 2002, at 12:26 PM, Zack Weinberg wrote:
> I was just about to post a request for the same exact semantics. I'd
> add only one thing:
>
> If svn resolve is invoked with no arguments, it operates iteratively
> on all conflicted files below the current working directory.
>
> (hence you can just go "svn resolve" at top level and do everything at
> once).
Yup. The --recurse-depth option proposed for other commands would be
handy here too.
> It would be nifty if svn resolve could be told "if there is a conflict
> in a file named "configure", first resolve any conflicts in files
> named "configure.in", "aclocal.m4", ..., then run autoconf in the same
> directory" -- but that might be excessive features. Certainly not for
> cut 1 of interactive resolve.
I think the cost/benefit ratio of this feature doesn't make it worth
doing, even post-1.0. It's not that much work for the user to do 'svn
resolve configure.in && autoconf'. Conversely, dependency analysis would
be a fairly large job to implement, and outside the scope of a version
control tool.
I wonder if you could define a sort of backwards make rule that would be
triggered by the *existence* of a target and be invoked to remove it.
Then you could make configure.in depend on the absence of
configure.in.rej for example.
Cheers,
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
Re: svn resolve: just what does it do?
Posted by William Uther <wi...@cs.cmu.edu>.
On 15/3/02 4:09 PM, "Bill Tutt" <ra...@lyra.org> wrote:
> 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.
I'd prefer something that used the svn:mime-type property. Possibly with a
way to have the svn:mime-type automagically set (based on a file pattern?)
when you add a file.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn resolve: just what does it do?
Posted by Bill Tutt <ra...@lyra.org>.
> 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
Re: svn resolve: just what does it do?
Posted by Zack Weinberg <za...@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.
I was just about to post a request for the same exact semantics. I'd
add only one thing:
If svn resolve is invoked with no arguments, it operates iteratively
on all conflicted files below the current working directory.
(hence you can just go "svn resolve" at top level and do everything at
once).
It would be nifty if svn resolve could be told "if there is a conflict
in a file named "configure", first resolve any conflicts in files
named "configure.in", "aclocal.m4", ..., then run autoconf in the same
directory" -- but that might be excessive features. Certainly not for
cut 1 of interactive resolve.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn resolve: just what does it do?
Posted by Ben Collins <bc...@debian.org>.
On Fri, Mar 15, 2002 at 12:11:19PM -0800, Colin Putney wrote:
>
> 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.
>
Change that to "When it exits with zero exit status...". If the merge
tool exits non-zero, we should not assume that the conflict is resolved.
--
.----------=======-=-======-=========-----------=====------------=-=-----.
/ Ben Collins -- Debian GNU/Linux -- WatchGuard.com \
` bcollins@debian.org -- Ben.Collins@watchguard.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn resolve: just what does it do?
Posted by Philip Martin <ph...@codematters.co.uk>.
Colin Putney <cp...@whistler.net> writes:
> 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.
Only delete if the merge tool reports success. I want to be able to
abort the merge and try again, or try something else.
We may want the merge tool to be configurable for each filetype, or do
we rely on an intelligent merge tool dispatching to the correct
filetype handler?
>
>
> 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.
Again, only delete if the editor reports success.
>
>
> 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.
>
>
> 4. If none of the above conditions are met, svn resolve errors out
> because the conflict wasn't resolved.
Perhaps if there is no conflict the command should just exit quietly.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: svn resolve: just what does it do?
Posted by Bill Tutt <ra...@lyra.org>.
> From: Colin Putney [mailto:colin@whistler.com]
>
> Philip Martin <ph...@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 <cp...@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
Re: svn resolve: just what does it do?
Posted by Colin Putney <co...@whistler.com>.
Philip Martin <ph...@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 <cp...@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
Re: svn resolve: just what does it do?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Colin Putney <cp...@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.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn resolve: just what does it do?
Posted by Colin Putney <cp...@whistler.net>.
On Friday, March 15, 2002, at 11:13 AM, Ben Collins-Sussman wrote:
> On the other hand -- now that we have 3 fulltext backup files, 'svn
> resolve' very well *could* invoke a 3rd-party merge tool. It could be
> configured in our ~/.subversion/ area, much like $EDITOR is. Is that
> a good idea?
I think it is.
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. OTOH,
figuring out which merge tool would be appropriate and launching it with
appropriate targets would be very useful.
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.
This keeps the current behaviour intact — you can still resolve the
conflict manually and then run svn resolve to delete the conflict
fulltexts — but you can configure more substantive and convenient
behaviour if you want.
Cheers,
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
Re: svn resolve: just what does it do?
Posted by Ben Collins-Sussman <su...@collab.net>.
Zack Weinberg <za...@codesourcery.com> writes:
> I'm a little confused by the "svn resolve" operation which has been
> described in some messages to this list. It sounds like all it does
> is delete the conflict-marker files, after the user has fixed up the
> file under conflict by hand.
Indeed, it's just a shortcut for removing the backup files; and the
existence of the backup files are the only thing that makes svn think
a file is in a state of conflict.
> I think users are more likely to expect that "svn resolve" invokes
> some sort of interactive conflict resolution utility. That's what
> Perforce and Bitkeeper both do with that subcommand.
Perhaps Perforce and Bitkeeper users might be confused, yes. But 'svn
help resolve' specifically prints a help message that dispels this
assumption. As should any other svn documentation.
On the other hand -- now that we have 3 fulltext backup files, 'svn
resolve' very well *could* invoke a 3rd-party merge tool. It could be
configured in our ~/.subversion/ area, much like $EDITOR is. Is that
a good idea?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org