Evaluate Changelogic without registration!
  

Conflict resolution

What is a conflict? A conflict occurs when the same or adjacent lines of a file have been edited, added and/or removed in several concurrent changes and the lines are then asked to be merged together. For binary files, conflict occurs when a new revision of the file has been checked in in multiple concurrent changes.

The development model used in Changelogic allows same file to be edited in several changes and does not require locking the file first; modifications made in different changes are later merged together. While we believe this to be very convenient to developers and a requirement for agile development, sometimes automatic merging is not possible because the edits are in the same set of lines. In such cases, manual human intervention is expected to sort out what the result should be.


In Changelogic, conflicts occur mostly when the code from one change is merged with other changes, such as when

  • performing base version update of a change
  • integrating a change
  • synchronizing with code not managed by Changelogic
  • starting development of a change

Finding conflicts in a code is not an easy task to perform. We even believe, that finding one might be very complicated (or even impossible) for a newbie. This is why Changelogic provides automatic conflict search. When user starts development of a change, performs base version update of a change, integrates a change or syncronizes code, Changelogic searches for a special conflict markers (<<<<<<, ========, >>>>>>) in programming code (text files). Once it's found, it is pointed out to a user by a message like:


[refresh] Conflicting file: C:\test\cl-test\changelogic-project.properties
or
[promptandstartdev] cvs checkout: conflicts found in cl-test/changelogic-project.properties


Conflicts found in version.properties and project.properties files are resolved automatically.


Both CVS and Subversion mark conflict areas in text files similarly:


When resolving conflicts, you should carefully study what has each conflicting edit been trying to achieve; then take code of one variant and perform edits that had been made in the other. In most cases, simply selecting one of the variants is not enough as that would discard the edits in the other variant altogether. Also, in many cases it is wrong to add together all unique lines from each variant, since one of the edits might have been removing some of the lines, and adding them back from the other variant would discard that edit. You should be extra wary when you see an empty variant between conflict markers, as this usually indicates that the conflicting code has been either deleted or moved into another location in one of the changes; to resolve such conflict, you should manually make edits in the other variant into the new location.


You can find diffs of a change on the change details page. For browsing diffs in mainline, observe the base version of the change being integrated (you can find it on the details page of the change) and the last version of the branch you are integrating into (e.g. from planning page); then use version differences page to browse edits made between the two versions.


Resolving conflicts is error-prone, as it is easy to miss out a small detail with huge impact in one of the conflicting edits and inadvertently discard it as a result of conflict resolution. Therefore project teams are advised to avoid base version updates when they are not necessary and grant integration permissions only to selected seasoned developers who would grow into experts of resolving conflicts.


Note that VCS detects conflicts only by watching adjacent lines that change. There are some rare occasions when two concurrent changes will not produce a conflict as in sense of VCS, but the code does not work when merged together. Perhaps the most common example is having a class or method renamed or removed in one change, while concurrently a reference to the same class or method has been added in another change.


Due to the nature of merging algorithms being line-oriented, there are some editing patterns that tend to cause many conflicts and are thus best avoided when there are other open changes, base version is not the latest or older release cycles need supporting:

  • reformatting whitespace, changing line terminators or anything similar, causing a large number of lines to change
  • reordering methods in a class
  • everybody keeps committing their personal preferences in the same file, overwriting the settings of previous committer