Changes between Version 9 and Version 10 of TracDev/DevelopmentWorkflow

Timestamp:

Mar 7, 2016, 12:15:10 AM (8 years ago)

Author:

Ryan J Ollos

Comment:

Adapt documentation to what we do in practice.

TracDev/DevelopmentWorkflow

@@ -13 +13 @@
 == Integration in release branches
 
-We commit bug fixes first on one of the stable branches, eg [source:branches/0.12-stable], then merge the fix to later branches using svn's mergeinfo support.
+We commit the change first on one of the stable branches, eg [source:branches/0.12-stable], then merge the fix to later branches using svn's mergeinfo support.
 
 Merging in this direction (//porting// or //forward porting//) makes it quite easy to merge all pending changes from one stable branch to the next, eg [source:branches/0.12-stable 0.12-stable] to [source:branches/1.0-stable 1.0-stable], then to [source:trunk]. This workflow is much simpler than the opposite one, //back porting//, which involves cherry-picking or careful "blocking" of changes which shouldn't be merged back. The SCM tools have generally better support for merging in this forward direction, even Subversion since v1.5.
+
+While this pattern of //forward porting// makes it easy to merge all pending changes, in practice we cherry-pick changes as they are committed in order to keep all branches in sync and prevent pending changes from accumulating on a branch.
 
 Here's a walk through example. We start by hacking on [source:branches/0.12-stable 0.12-stable]:
@@ -24 +26 @@
 (all is good)
 0.12-stable$ svn ci -m "0.12.6dev: fixed ... (#xyz)"
+...
+Committing transaction...
+Committed revision 15410.
 }}}
 
-Now we want to port all the pending changes to [source:branches/1.0-stable]:
+Now we want to the change to [source:branches/1.0-stable]:
 {{{#!sh
 0.12-stable$ cd ../1.0-stable
-1.0-stable$ svn merge ^/branches/0.12-stable
+1.0-stable$ svn merge -c 15410 ^/branches/0.12-stable
 1.0-stable$ make test
 ...
@@ -35 +40 @@
 1.0-stable$ # some fixes needed for API changes
 1.0-stable$ svn ci -m "1.0.2dev: Merged from 0.12-stable."
+...
+Committing transaction...
+Committed revision 15411.
 }}}
 
-Now we want to port all the pending changes to [source:trunk]:
+Now we want to port the change to [source:trunk]:
 {{{#!sh
 1.0-stable$ cd ../trunk
-trunk$ svn merge ^/branches/1.0-stable
+trunk$ svn merge -c 15411 ^/branches/1.0-stable
 trunk$ make test
 ...
@@ -46 +54 @@
 trunk$ # some fixes needed for API changes
 trunk$ svn ci -m "1.1.2dev: Merged from 1.0-stable."
+...
+Committing transaction...
+Committed revision 15412.
 }}}
 
 Among the possible porting related fixes that should be done when porting:
  - Use Python idioms adapted to the minimal version on the branch, eg for Trac 0.12 the baseline is Python 2.4, for Trac 1.0 and trunk it's 2.5; this means that among other things we can use `with ...` as appropriate.
- - Use newer APIs and conventions, eg the DatabaseApi#Trac0.13API; see the ApiChanges subpage for the corresponding target branch.
+ - Use newer APIs and conventions, eg the DatabaseApi#Trac1.0API; see the ApiChanges subpage for the corresponding target branch.
 
-'''Note''': you can always review what are the pending changes in Trac by looking at the `svn:mergeinfo` property which shows the '''eligible''' set of changesets, when viewing the target branch in the TracBrowser, eg [source:trunk].
+If a changeset should not be forward ported, for example when extracting new messages to the catalog, the commit should be blocked using a //record only// merge. The //record only// merge is the same as a cherry-pick merge, with the addition of the `--record-only` switch.
+
+'''Note''': you can always review the pending changes by viewing the `svn:mergeinfo` property in the TracBrowser, eg [source:trunk], which shows the changesets that are **eligible** for merge to the target branch.
 
 == Pushing from a DVCS to SVN