[RFC] How to better assist users in resolving conflicts

Alexander Belchenko bialix at ukr.net
Wed Jan 13 09:04:08 GMT 2010


Vincent Ladeuil пишет:
>>>>>> "martin" == Martin Pool <mbp at canonical.com> writes:
> 
>     martin> 2010/1/13 Vincent Ladeuil <v.ladeuil+lp at free.fr>:
>     >> So far we have only one command when it comes to resolving the
>     >> conflicts: 'bzr resolve' with 'resolved' alias.
> 
>     martin> It would be a bit confusing to have 'resolve' and
>     martin> 'resolved' exist as different commands, so I'd like
>     martin> to see if we can I think, as part of
>     martin> <https://bugs.edge.launchpad.net/bzr/+bug/506265> we
>     martin> should remove the 'resolved' alias.
> 
>     martin> It looks like you're planning to keep the general
>     martin> model that after a merge your working tree is marked
>     martin> with some things as conflicted, which I think is
>     martin> fine.  We can then let the user deal with the
>     martin> conflicts either by running a sequence of
>     martin> non-interactive commands, or by popping into
>     martin> something that asks them questions about a whole
>     martin> series of conflicts.
> 
> So I stepped back from doing so in the core and decided to leave
> that for GUIs.
> 
> The rationale is that:
> 1) We need to provide a scripted way to access the feature,
> 
> 2) As soon as we let the user modify the working tree *during* an
> interactive session, there are a lot more checking that needs to
> be done and a lot more work to make the code more robust.
> 
> GUIs can build interactive sessions on top of that as long as we
> provide the necessary steps:
> 
> - list the conflicts,
> - list the possible actions for a given conflict,
> - resolve a given conflict with a given action.
> 
> Implementing a GUI presenting the list of conflicts with a menu
> containing the possible actions for each one should then become
> quite easy.

We have one: qconflicts.

One thing that constantly irritate me: why `bzr resolve --auto` don't 
auto mark file path conflict as resolved when I manually change the 
paths (foo vs foo.moved) as needed? So I remove/rename foo.moved and 
there is no more conflicted file, but `bzr resolve` won't make my life 
easier. Why? Ditto for binary files conflicts. If I delete OTHER/THIS 
then there is no more conflict? No?




More information about the bazaar mailing list