Bazaar

Bazaar

 

Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Summary

Enhance conflict resolution experience by giving better explanations and easier ways to resolve conflicts.

Rationale

Conflicts occurs rarely and the better the merge algorithms will be, the less conflicts the users will have to resolve.

What happens then is that users are not familiar with conflicts and get a bit lost when conflicts occur because they have trouble understanding what the conflicts are about.

bzr should provide an easy access to conflict explanations and propose the easiest ways to resolve the conflicts.

For text conflicts, the most common way is for the user to edit the file and chose between the proposed versions. This kind of manual resolution is outside the scope of this spec.

This spec is about giving better explanations about what is involved in the conflicts and propose simple actions to resolve them.

The workflow

The typical workflow when encountering text conflicts is: 

    bzr merge
    hack FILE
    hack ...
    hack FILEn
    bzr resolve
    bzr commit

The typical workflow when encountering tree shape conflicts (all the other conflict types) is: 

    bzr merge
    wow, what's that ?
    bzr revert

    bzr merge
    damn, there they are again
    bzr resolve --all
    bzr commit
    pfew, they are gone

This led to:

This spec is about making the workflow like: 

   bzr merge
   nnn conflicts encountered (see 'bzr conflicts -v' for details).
   bzr conflicts -v
   FILE1: FILE1.THIS is a file, while FILE1.OTHER is a directory
      Use --take-this to keep FILE1 as a file
      Use --take-other to make FILE1 a directory
   ....
   bzr resolve FILE1 --take-this   
   bzr commit

bzrlib will allow GUI authors to provide an even better interactive resolution. bzr will focus on providing a scriptable interface.

Implementation plan

Add actions to bzr resolve

Merged as of lp:bzr revision: 5009 revid:pqm@pqm.ubuntu.com-20100205113358-wd4d49omal1hus75

Related bugs:

Add missing attributes to conflict types

Text conflicts

The base file revision will provide better context to resolve conflicts, this may be done in addition to using better conflict markers.

Non-directory parent

The generated 'FILE.new' should be renamed 'FILE.OTHER' and the path used added as 'conflict_path'.

== Better conflict explanation ===

bzr conflicts -v can display more details about what action can be used to resolve the conflicts.

Additionally, it should be mentioned at the end of a merge that generated conflicts, changing: 

     nnn conflicts encountered.
  • into 

     nnn conflicts encountered (see 'bzr conflicts -v' for details).

Once every conflict object has the relevant attribute, implement a check to add to forbid adding files that are known to have been generated at merge time to help conflict resolution.

If the files are specified explicitly, just accept them.

Merged as of lp:bzr revno: 5031 revid:pqm@pqm.ubuntu.com-20100211114855-owq7q18cogsdbbpc

Related bugs::

Use .THIS/.OTHER for all conflict types

Handle more conflict types with --auto

So far, the "automatic" resolution exist for text conflicts only: if no more markers are found in the file, the conflict resolution is considered to be finished and the file is marked as such.

There are more conflict types that could be allowed to be seen as resolved as long as the working tree *is* in a valid state.

This spec proposes to implement that kind of check for more conflict types than just the text ones by defining a --auto action.

The --done action will retain its actual meaning of: delete the conflict and the generated files whatever the state.

From there, commit may attempt bzr resolve --auto before complaining about the remaining conflicts.

Related bugs::

Content conflicts

If either .THIS or .OTHER doesn't exist any more and FILE exists again, --auto could consider the conflict as resolved.

Duplicate paths

Checking that 'FILE.moved' doesn't exist any more must be enforced both when --action=done is used and at bzr commit time or FILE.moved should be automatically removed and unversioned.

Missing parent

Arguably any state is valid after the merge so bzr can just consider the conflict as resolved.

Deleting parent

The most annoying case here is when the directory contains junk files. If we knew how to identify them, then the default resolving action can be to get rid of them.

Path conflict

Arguably acknowledging Bazaar choice should be an acceptable resolution, and *any* name is valid as a conflict resolution at that point.

Parent Loop

Any layout is valid and should be considered as an acceptable resolution.

Non-directory parent

If .new doesn't exist any more, --auto may consider marking the conflict resolved.

Provide additional actions for text conflicts

There are 6 ways to resolve text conflicts:

  1. Manually
  2. take-this choose THIS in conflicted regions
  3. take-other choose OTHER in conflicted regions
  4. take-both take THIS and OTHER in conflicted regions
  5. restore-this take THIS overriding all cleanly merged modifications
  6. restore-other take OTHER overriding all cleanly merged modifications

take-this, take-other and take-both should apply to the file as present in the working tree so that they could be used even if some conflicts have been already resolved by the user.

take-this, take-other and take-both may be more natural to use if implemented by merge/remerge too.

TODO

  • - make sure .moved files can't be committed ? - tests with '.diverted' files ? - provides a description of the conflict - provides a description of the commands that will be issued by
    • --take-this and --take-other (--dry-run ? conflicts -v)
    - resolve actions are brittle if the working tree has been
    • modified (files renamed, moved, etc), leave that to GUIs
    - look at bumping the CONFLICT_HEADER_1 to add more attributes to
    • conflict objects. Considering that the file is short-lived we may just want to *not* support upgrades or give the alternative: bzr revert or delete checkout/conflicts + commit.
    - check that 'text conflict' and 'tree shape conflict' are
    • clearly defined somewhere.

Related bugs

The following are not directly addressed by this spec but provide some additional context::

The following are related too::