TPPDev:Branching

From SPCTools

(Difference between revisions)
Jump to: navigation, search
Revision as of 23:05, 25 October 2011
JoeS (Talk | contribs)

← Previous diff		 Revision as of 20:19, 26 October 2011
JoeS (Talk | contribs)

Next diff →
Line 1: Line 1:
 +== The Condensed Version ==
 +
 +* If you want your check in to be shipped with the next minor/bugfix release, then check into the current branch only. And use svn merge to get branch to trunk or ask Joe to do it.
 +
 +* Otherwise, check it in into trunk only.
 +
 +* But never commit the same thing to both.
 +
== Branch Policy == == Branch Policy ==

Revision as of 20:19, 26 October 2011

Contents

The Condensed Version

  • If you want your check in to be shipped with the next minor/bugfix release, then check into the current branch only. And use svn merge to get branch to trunk or ask Joe to do it.
  • Otherwise, check it in into trunk only.
  • But never commit the same thing to both.

Branch Policy

  • trunk/ - Contains the latest development changes. Should always be buildable, but may not always be runnable. Nightly a script builds the latest trunk and installs it on a linux system at ISB (/proteomics/sw/tpp-dev, for those who are interested). The results of this nightly build are emailed to TPP developers.
  • branches/<major.minor> - This branch contains the source for specific versions of TPP, where <major.minor> is the TPP version, e.g. 4.5. When preparing a release, the trunk is first copied into a new version branch only when the development trunk is considered stable enough and ready to be released. All new development proceeds on the trunk. Any code changes (fixes) identified during testing of the branch are checked into the branch. I'd leave it up to each individual developer to decide whether their change is "new development" or a "fix" These change(fixes) are then merged into the trunk at one of two points: 1) after being checked in if its an important enough fix or 2) as the last step to preparing the release (see merging below for more info on merging). When the branch is ready for release a copy of the branch is made into /tags (see below). Should further maintenance/development be done on a released branch these changes will also be checked in on the branch, using the tag as a marker between releases. And lastly it may be necessary to merge specific trunk changes into an existing branch, but this should not be a common occurrence.
  • branches/<miscellaneous> - These are branches made to test out or do significant changes to TPP and you don't want to break the trunk for other developers. For example we could've done the mzParser changes on a special branch so that the changes could be tested separately and not affect the TPP class. When time comes then we can either choose to merge the branch into the trunk or delete it. (Though IMHO we should have a policy of deleting the branch in either case.)
  • tags/<release_<major>-<minor>-<rev> - contains the actual TPP release. Copied from a branch at the time of the release.

Merging

As you all know we are using subversion for our source code repository provided by sourceforge. One of the newer features (well, almost new, 1.5+) is the expended concept of a "merge". In the past svn contained an operation called a merge but it was mostly just another type of commit. It was the responsibility of SVN users to keep track of which changes where merged between trunk and branches. To address this most development teams would invent a complicated commenting policy, such as "[merge] branch 4.51 r5440:r5454 branch to trunk".

Fortunately now that we are out of the dark ages of svn versions here at ISB we should be able to take advantage of the new merging features. Essentially what this feature does is keeps track of which revisions have been merged between branches. These are tracked using properties ("svn:mergeinfo" on the revision tree. I won't go into more detail about how all that works since the svn manual does a better job (references below), but here are at least some tips. (PLEASE DO NOT TRY YET UNTIL MERGING IS IMPLEMENTED IN OUR REPOSITORY). And if all this doesn't make much sense to you, don't worry as I can handle running the merges. Just please check in your changes to the right places and we can get it sorted out.

Fixing a bug on the branch (nothing new here)

% cd ~/TPP-4.6
% svn update
...fix...build...test
% svn commit -m "fixed a nasty bug"

Merging your fixed bug into the trunk 

% cd ~/TPP-trunk
% svn update
% svn merge --reintegrate ~/branches/TPP-4.6/trans_proteomic_pipeline
...build...test....
% svn commit

Merging some trunk changes into your branch 

% cd ~/TPP-4.6
% svn update
% svn merge ~/trunk/trans_proteomic_pipeline

What changes are still eligible to merge from branch to trunk? 

% cd ~/TPP-trunk
% svn mergeinfo ^/branches/TPP-4.6 --show-revs eligible

What changes have already been merged from trunk to branch? 

% svn mergeinfo ^/calc/trunk

What isn't necessary

  • Checking a change into both the trunk and the branch. This can create merge "hell" with merge conflicts. Plus its extra unnecessary work that might not always be done correctly.

What is necessary

  • Using "svn merge". Most developers will likely want to keep two development sandboxes, one containing the trunk and one containing the most recent release. (I call mine TPP-trunk and TPP-4.5). That way if they are fixing a important issue they can easily check it into the right branch.
  • Checking into the right branch.

References

Retrieved from "http://tools.proteomecenter.org/wiki/index.php?title=TPPDev:Branching"
Personal tools