File Merge: How did we get ourselves into this mess


the file is now 5.

The responsibility for merging is going to fall upon Joe.  When he tries to checkin his changes, the SCM tool will protest.  His baseline version is 4, but the current version in the repository is now 5.  If Joe is allowed to checkin his version of the file, the changes made by Jane in version 5 will be lost.  Therefore, Joe will not be allowed to checkin this file until he convinces the SCM tool that he has merged Jane's version 5 changes into his working copy of the file.

Vault reports this situation by setting the status on this file to be "Needs Merge", as shown in the screen dump below:

Best Practice: Keep the repository in sight

This example happens to involve the need to merge only a single checkin.  Since Joe's baseline is 4 and the current repository version  is 5, Joe is only 1 version out of date.  If the repository version were 25 instead of 5, then Joe would be 21 versions out of date instead of just 1, but the technique is the same.  No matter how old his baseline is, Joe still needs to retrieve the latest version and do a three-way merge.  However, the older his baseline, the more likely he is to encounter conflicts in the merge. 

Keep in touch with the repository.  Update your working folder as often as you can without interrupting your own work. Commit your work to the repository as often as you can without breaking the build. It isn't wise to let the distance between your working folder and the repository grow too large.

In order to resolve this situation, Joe effectively needs to do a three-way comparison between the following three versions of the file: 

    • Version 4 (the baseline from which he and Jane both started)  
    • Version 5 (Jane's version)


  • Joe's working file (containing his own changes)

Version 4 is the common ancestor for both Joe's version and Jane's version of the file.  By running a diff between version 4 and version 5, Joe can see exactly what changes Jane made.  He can use this information to apply those changes to his own version of the file.  Once he has done so, he can credibly claim that his version is a merge of his changes and Jane's.

Strictly speaking, Joe is responsible for whatever changes Jane made, regardless of how difficult the merge may be.  He must perform the changes to his file that Jane would have made if she has started with his file instead of with version 4.  In theory, this could be very difficult: 

  • What happens if Jane changed some of the same lines that Joe changed, but in different ways?  
  • What happens if Jane's changes are functionally incompatible with Joe's?  
  • What happens if Jane made a change to a C# function which Joe has deleted?  
  • What happens if Jane changed 80 percent of the lines in the file?
  • What happens if Jane and Joe each changed 80 percent of the lines in the file, but each did so for entirely different reasons?  
  • What happens if Jane's intent was not clear and she cannot be reached to ask questions?

All of these situations are possible, and all of them are Joe's responsibility.  He must incorporate Jane's changes into his file before he can checkin a version 6.

In certain rare situations, Joe may examine Jane's changes and realize that his version needs nothing from Jane's version 5.  Maybe Jane's change simply isn't relevant anymore.  In these cases, the merge isn't needed,

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.