Changes between Version 9 and Version 10 of TracDev/DevelopmentWorkflow
- Timestamp:
- Mar 7, 2016, 12:15:10 AM (8 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/DevelopmentWorkflow
v9 v10 13 13 == Integration in release branches 14 14 15 We commit bug fixesfirst on one of the stable branches, eg [source:branches/0.12-stable], then merge the fix to later branches using svn's mergeinfo support.15 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. 16 16 17 17 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. 18 19 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. 18 20 19 21 Here's a walk through example. We start by hacking on [source:branches/0.12-stable 0.12-stable]: … … 24 26 (all is good) 25 27 0.12-stable$ svn ci -m "0.12.6dev: fixed ... (#xyz)" 28 ... 29 Committing transaction... 30 Committed revision 15410. 26 31 }}} 27 32 28 Now we want to port all the pending changesto [source:branches/1.0-stable]:33 Now we want to the change to [source:branches/1.0-stable]: 29 34 {{{#!sh 30 35 0.12-stable$ cd ../1.0-stable 31 1.0-stable$ svn merge ^/branches/0.12-stable36 1.0-stable$ svn merge -c 15410 ^/branches/0.12-stable 32 37 1.0-stable$ make test 33 38 ... … … 35 40 1.0-stable$ # some fixes needed for API changes 36 41 1.0-stable$ svn ci -m "1.0.2dev: Merged from 0.12-stable." 42 ... 43 Committing transaction... 44 Committed revision 15411. 37 45 }}} 38 46 39 Now we want to port all the pending changesto [source:trunk]:47 Now we want to port the change to [source:trunk]: 40 48 {{{#!sh 41 49 1.0-stable$ cd ../trunk 42 trunk$ svn merge ^/branches/1.0-stable50 trunk$ svn merge -c 15411 ^/branches/1.0-stable 43 51 trunk$ make test 44 52 ... … … 46 54 trunk$ # some fixes needed for API changes 47 55 trunk$ svn ci -m "1.1.2dev: Merged from 1.0-stable." 56 ... 57 Committing transaction... 58 Committed revision 15412. 48 59 }}} 49 60 50 61 Among the possible porting related fixes that should be done when porting: 51 62 - 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. 52 - Use newer APIs and conventions, eg the DatabaseApi#Trac 0.13API; see the ApiChanges subpage for the corresponding target branch.63 - Use newer APIs and conventions, eg the DatabaseApi#Trac1.0API; see the ApiChanges subpage for the corresponding target branch. 53 64 54 '''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]. 65 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. 66 67 '''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. 55 68 56 69 == Pushing from a DVCS to SVN