tortoisebzr-developers team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
> There was some discussion on IRC between lifeless and myself about how a
> 'resolve' GUI should work in TortoiseBzr/QBzr.  We both agreed it was worth
> getting a broader view on this, and he asked me to also keep the discussion
> on the main bzr list - hence the cross-post to 3 lists.  (Note that not all
> UI discussions will be cross-posted to the bzr mailing list - if you have an
> interest in the UI models for TortoiseBZR or QBzr, I urge you to join one of
> the relevant mailing lists.)
> 

Let me first try to discuss how I resolve conflicts as at least one possible
use case, and then we can work around it.

90% of the time when a file is conflicted I do:

vim file
/<<<<\|====\|>>>>

And jump between the conflicted sections. As the most common conflict is NEWS,
I also tend to just delete the conflict markers, and make sure the entries are
sorted.

Then back to the command line for
bzr resolve

If there are lots of files conflicted, I may do more:
vim file
bzr resolve file
vim file2
...

Though honestly the "bzr resolve" is good enough that I rarely supply
filenames anymore. It also helps that auto-resolve won't resolve a file with
markers in it, so that I don't have to worry about "missing" a conflict.


Other things I do can be:

bzr remerge --reprocess

If the hunks are unbearable. This is fairly rare anymore, though I still think
we should make the default --reprocess, and just have it disabled if someone
supplies --show-base. (--show-base is incompatible with --reprocess because
you lose the context to know what base was, as both THIS and OTHER are
different from BASE in the whole range.)

If we had a criss-cross merge, I almost always do:

bzr remerge --weave

3-way merge really conflicts badly under criss-cross. And there is a very
simple way to create it. Just merge the same feature into 2 "integration"
branches and then merge them together. (Possibly you have to merge more than
one feature into both.)

I did it accidentally when merging the changes into 1.6rc?, because I forgot
to supply --submit-branch to pqm-submit. Regardless, though, people with
multiple stable branches will run into this a lot (mysql does).

If we want to keep 3-way as 3-way, then I would recommend we at least go down
to per-file graphs after criss-cross. Alternatively, if we detect criss-cross
we could just enable --lca or --weave, which will both do a better job. (I
would vote for --weave at the moment, but both have things they don't conflict
on, which one can argue about.)

Things I don't do, but others do:

Spawn a GUI 3-way merge utility, using the BASE, OTHER, THIS files.

My biggest problem here is that few GUIs implement vim style editing, which is
just powerful enough to negate all the other benefits.

However, people using TortoiseBzr are likely to want a 3-way resolver.


> The question is:
> 
> * If a file is shown as being in conflict, what 'resolve' related operations
> should appear on its menu, and what UI, if any, should be shown when
> selected?

I would probably give them

1) "force resolve" (possibly just 'resolve') to remove the conflict,
2) *maybe* "auto resolve" to check and see if the conflict is done,
3) and an option to spawn their preferred 3-way editor. The main problem I
   see, is that you don't really want to edit the .THIS file, you want to move
   foo => foo.CONFLICTED, and foo.THIS => foo, and then 3-way merge 'foo',
   'foo.BASE', 'foo.OTHER'. That way when they finish editing "foo" in that
   editor the changes are in the final file.

> 
> * If a directory has one or more children in conflict, what 'resolve'
> related operations should appear on its menu, and what UI, if any, should be
> shown when selected?

1) Don't forget that directories can, themselves, be in conflict. (One person
   deleted a dir, another person added a file, or modified a file underneath
   there.)
2) The biggest one for me is "auto-resolve", to recurse and resolve any files
   that are already "clean". Note that stuff like binary file conflicts, or
   directories becoming files, etc, do not have an "auto-resolve" ability.
3) "resolve" for a directory could pop up a dialog showing what is in
   conflict, and allow the users to mark which files have been resolved,
   possibly having "double-click" spawn an editor.

> 
> * Should Tortoise attempt ever attempt to auto-resolve files without any
> interaction from the user?  If so, in what cases should it perform that
> check?  If not, how does auto-resolve fit into this model?

I wouldn't do this (yet). You *could* monitor the filesystem, and if you see a
"save" occur on one of the files, you could try to auto-resolve it. There are
cases where that breaks, though. (Say they tried one thing, save the file
which makes it looks resolved, but breaks the test suite. Then want to come
back and use the 3-way editor to resolve it a different way, but as it isn't
in conflict, there are no THIS/BASE/OTHER files to use.)

> 
> I've purposely kept the question open and refrained from offering any of my
> own opinions.  What do you think a GUI user would expect to see in the case
> of a file/directory with conflicts, specifically taking the 'auto-resolve'
> capability of bzr into account?
> 
> Thanks,
> 
> Mark
> 
> 

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIu/mZJdeBCYSNAAMRAskKAKCYCYAR2+NELYOvbFXk2MEJeMr02ACgtL5W
x21c1rK0YOvo5hlB694Sxc8=
=j2UI
-----END PGP SIGNATURE-----