Difference between revisions of "Managing Commits in Trunk and Release Branches"

From Mpich
Jump to: navigation, search
(Merging changes to Release Trees and Branches)
(Merging changes to Release Trees and Branches)
Line 27: Line 27:
 
shell$ svn commit
 
shell$ svn commit
 
</pre>
 
</pre>
It is essential that the <code>svn commit</code> is applied just as shown - do not restrict the commit to a single file or directory, and apply it '''only''' in the top-level directory.
+
It is essential that the <code>svn commit</code> is applied just as shown - do not restrict the commit to a single file or directory, and apply it '''only''' in the top-level directory.  This is true even if an <code>svn status</code> show property changes (an 'M' in the second rather than the first column) for files unrelated in any way to the files you just merged.
  
 
If the commit fails because of changes in <code>src/pm/hydra/VERSION</code>, try the following:
 
If the commit fails because of changes in <code>src/pm/hydra/VERSION</code>, try the following:

Revision as of 17:41, 10 December 2010


Release Trees and Branches

  • Trunk represents the next major version release of MPICH2.
  • A tree represents a major version series (such as 1.3.x) and can be found in the https://svn.mcs.anl.gov/repos/mpi/mpich2/branches/release directory (the "x" here is a literal - it does not stand for a number). As soon as trunk starts tracking the next major version series, an svn tree is created to track the current stable major version series. Note that the tree does not appear on the roadmap page.
  • A branch represents a specific release version (such as 1.3.1) and can be found in the https://svn.mcs.anl.gov/repos/mpi/mpich2/branches/release directory. A release branch is created just before an RC release is made for that version.

Commits in Trunk

  • The trunk should be a superset of all release related commits. All commits should be made to trunk first, and then merged into the release branches. An exception to this rule are commits that are obviously only related to a specific release (such as updating the maint/Version information).

Merging changes to Release Trees and Branches

  • All commits that do not break the ABI string for a stable major release, should also be committed into the major release tree for as long as the release tree is maintained. For example, any commits to trunk that do not break the ABI string of the 1.3.x release series, should also be committed to the 1.3.x tree.
  • The following steps can be followed for merging changes to a branch or tree:
  1. Create the fix in the trunk; test it and check it in. Remember the change-number, or it can be found here: https://trac.mcs.anl.gov/projects/mpich2/timeline
  2. Follow these steps for the release branch mpich2-X.Y.Z:
shell$ svn co https://svn.mcs.anl.gov/repos/mpi/mpich2/branches/release/mpich2-X.Y.Z

shell$ cd mpich2-X.Y.Z

shell$ svn merge -c <change-number> https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk .

shell$ svn commit

It is essential that the svn commit is applied just as shown - do not restrict the commit to a single file or directory, and apply it only in the top-level directory. This is true even if an svn status show property changes (an 'M' in the second rather than the first column) for files unrelated in any way to the files you just merged.

If the commit fails because of changes in src/pm/hydra/VERSION, try the following:

shell$ svn revert src/pm/hydra/VERSION

shell$ svn commit

Tracking Release Versions

The current release roadmap information can be found here: https://trac.mcs.anl.gov/projects/mpich2/roadmap