tortoisebzr-developers team mailing list archive

["C. Mundi" <cmundi@xxxxxxxxx>]

Hi Mark.

The first two parts of your question really have no wrong answers.
Workflows for resolutions will vary, but anything which gives me an option
to go through each of the files (in any order) and do 3-way merges on each
would be great.  Actually, now that I think about it... the ability to go
back and change how I resolved a conflict in one file after resolving a
conflict in another file (known in technical parlance as "changing my mind"
<grin>) would be most appreciated.

The third part strikes a powerful chord for me.  If TBzr ever has an
auto-resolve capability, I want to be able to turn it off.  Thankfully
rarely, I have to deal with a situation where a gatekeeper thought  that
"the *right* way to resolve that conflict was obvious" [direct quote] and
that she didn't need to consult with developers.  The thing is, she's right
95% of the time.  But the other 5% of the time she incurs productivity
losses for an entire team, which can easily wipe out the "savings" in the
other 95% of cases she got right -- especially if I have to get involved to
calm people down.  So It comes down to simple economics for me.  I'm paying
people to work as a team, to produce the best possible product -- not to
show me how smart they are as individuals.  My point is that merge conflicts
are social challenges.  The key to success is collaboration, not one person
-- or one algorithm -- making unilateral judgments.  There's nothing wrong
with offering an auto-resolve.  I just want to be able to turn it off.
Thanks for indulging my rant.

cm


On Sun, Aug 31, 2008 at 8:54 PM, Mark Hammond <mhammond@xxxxxxxxxxxxxxxx>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.)
>
> 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?
>
> * 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?
>
> * 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'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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~tortoisebzr-developers<https://launchpad.net/%7Etortoisebzr-developers>
> Post to     : tortoisebzr-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~tortoisebzr-developers<https://launchpad.net/%7Etortoisebzr-developers>
> More help   : https://help.launchpad.net/ListHelp
>