|
Most merge tools take, as parameters, a common ancestor file and two files that have been changed (from that ancestor) in parallel, perhaps repeatedly. If you look at the history of a file (and the extension to a change package is straightforward), and we'll keep this history really simple, you will see something like the following: myfile.cpp 1.01 .. 1.02 .. 1.03 .. 1.04 .. 1.05 .. 1.06 .. 1.07 Now let's assume that the change that created 1.04 (from 1.03) was not a good change and needs to be yanked out of the file. Your merge tool can do this by considering 1.04 as the common ancestor and 1.03 and 1.07 as parallel changes to 1.04. It may help you to visualize it by pulling 1.03 out of the chain (or even making a copy of it) and considering it as a parallel branch created from 1.04. The fact that it didn't happen that way doesn't really matter. If you compare 1.03 to 1.04, you will see the original change. If you compare 1.04 to 1.03, you will see the inverse change. The inverse change is going to be merged into 1.07. It is what actually causes the original change to be yanked. I remember one time when we had integrated a merge tool into CM+ and mixed up the order of the file parameters to the merge tool. It was quite embarassing as each reconcile operation (merge of a parallel checkout with the latest branch version), rather than reconciling the intermediate changes with the parallel checkout, yanked all the changes made by the parallel checkout. A quick edit of the configuration file to swap the order of the files quickly fixed the problem. But I'm sure it made it quite clear to the user that a yank operation is nothing more than a merge operation. When talking about individual files Neuma generally speaks about merging in four separate use cases:
There are of course other ways to view merge - a primary case being with respect to your entire workspace. But that's another topic. Joe Farah is the President and CEO of Neuma Technology. Prior to co-founding Neuma in 1990, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
Set as favorite
Bookmark
Email this
Hits: 10486 Trackback(0)Comments (0)
|
| Last Updated on Tuesday, 24 January 2006 05:09 |



