Notes on Merging using SVN and T-SVN

In trying to provide some help on merging with SVN, especially with the new “mergeinfo” functionality, I discovered a number of things that anyone doing branching and merging with SVN (Subversion) or T-SVN (TortoiseSVN) should know.

  • SVN and T-SVN treat revision numbers differently, especially with regards to deltas (i.e. a difference between pairs of files, directories or trees). This has been described in terms of “fence posts versus fence panels”. When expressing a delta, SVN sees the revision numbers as posts, T-SVN sees them as panels. For example, suppose that <file.txt> in the repository has the following revisions associated with it: 100, 130, 170, 200. The difference between the versions of <file.txt> at revisions 100 and 200 is expressed in SVN as 100:200. However, in T-SVN it is 130-200. That is, with SVN you ask “show me the difference between revsions 100 and 200”, whereas with T-SVN you ask “show me the difference resultion from revisions 130 to 200.
  • When a (feature) branch is “reintegrated” with the trunk, it is usually the case that the branch is no longer viable for further development, and the branch should be deleted. It is not the “reintegration” per se that it the problem; rather, it is the possibility of “cyclic merges”. This occurs when a branch development is regularly “synchronised” with the trunk, i.e. when revisions from the trunk are merged to the branch; this is “best practice” as it spreads the pain of reintegration. Further work should not continue on the branch; it should instead be on a fresh branch from the trunk.
  • When merging trees, it can be dangerous to specify the HEAD as the left tree, which usually also corresponds to the target tree. That can result in the inadvertent reversion of recent trunk revisions. Therefore it is good practice to always specify revisions explicitly by number for merge operations.
  • SVN mergeinfo in subdirectories can cause problems with a merge. For example, Tortiose might refuse to reintegrate. Therefore always perform any merge operations in the root directory of your project sources so that all the mergeinfo accumulates there.
  • Always merge to a simple, up-to-date, clean working copy, i.e. one which is up to date to a simple single revision, and with no local modifications.
  • It is good practice to synchronise a branch before merging it.
  • A merge isn’t really a merge: it is slightly misnamed. It is really the application of a difference. A merge involves three trees, the left, the right and the target; often the left and the target are the same, or at least on the same path. Often, as with reintegration of a synchronised branch, the result of a merge is expected to be a trunk that is now the same as the branch.

On the positive side

  • A merge operation works locally, and requires a separate commit. Therefore, if there are problems, it is possible to undo and redo the merge, without affecting the repository. The commit, of course, should only be executed after checking and testing the result of the merge.

This and more may be read about in the following places:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: