When Large Teams Shrink


It is always best to do a full repository conversion whenever possible. If you are doing an archival it is strongly recommended. The problems will come up when there is not a one-to-one mapping between either the (meta)data maintained, or the implementation of core concepts is so different it is hard to map them. Each of the tool sets listed above have repositories that must be migrated, but for the purposes of this article some of the problems in migrating Version Control repositories will be addressed.

There are core concepts such as branching vs. streams, promotion vs. tags vs. snapshots, unique name spaces vs. unique object identifiers, and whether or not directory structures are versioned that have to be addressed. It generally the case that during a downsizing it will be a conversion from a more complex tool to a simpler one. To do that, try to do a logical decomposition of the individual versions of each object. You need to determine if there is a way to even map them to a simpler tool before you lock yourself into that new tool.

Unless both tools are able to uniquely identify each of the objects, regardless of their names and locations, it will not be possible to keep track of their movements, name changes, content merges, etc. It is also important to keep the timing of the individual changes (revisions) of each object, so it is not normally possible to simply populate each branch in turn. In other words, the transaction history of the repository must be reproduced or data may be lost. Depending on how large a repository is and how many transactions have occurred, it may take days or weeks to do the brunt of the work, always knowing that there will be a last minute “catch up” just prior to cut over.

“Tip” Repository Conversion
If it is not necessary to keep the past history going forward (and this is especially the case where one is not trying to comply with CMMI levels 4 or above, perform trend analysis, or need many past releases for other purposes), then just keeping the active branches/streams and the tip revisions of all active objects on them is an option. In the figure above, consider (4) and (5) represent current active branch/stream tips. In older generation Version Control tools, it would be enough to just create the branches and check in the tip revisions for each of the files. Later generation tools know that a more transaction-based ordering needs to be performed, though it does not necessarily need to be the same order as originally occurred. For the steps below, (1), (2), (3) and (5) can be considered to be on branch Main and (4) is on branch Branch. Note that superscripts indicate name and/or location changes and subscripts indicate revisions (content changes independent of name or location changes).

Main: Dir_1 and Dir_2 created
Main: Dir_1/File_A 2, Dir_1/File_B 1 and Dir_1/File_C 1 created
--- Branch created  ---
Main: Dir_1/File_B 1 modified, moved to Dir_2 and renamed to B 12
Main: Dir_2/File_C 1 modified
Branch: Dir_1/File_A 2, modified, moved to Dir_2 and renamed to A 13
Branch: Dir_2/File_C 2 modified to File_C 3
--- Merge started ---
Main Dir_1/File_A 2 merged with Branch Dir_2/File_A 13 and renamed to form Main Dir_2/File_A 24
Main Dir_2/B1 2 modified
Main Dir_2/File_C 2 merged with Branch Dir_2/File_C 3
Main Dir_1/File_D 1 created

Again, tools other than Version Control will have their own problems to be solved, but I hope this example will give some indication as to the level

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.