diff options
Diffstat (limited to 'admin/notes')
| -rw-r--r-- | admin/notes/bzr | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/admin/notes/bzr b/admin/notes/bzr index a743331820c..c66cdd98a3c 100644 --- a/admin/notes/bzr +++ b/admin/notes/bzr | |||
| @@ -26,6 +26,14 @@ small number of "real" commits, but several "merge from trunks", it is | |||
| 26 | preferred that you take your branch's diff, apply it to the trunk, and | 26 | preferred that you take your branch's diff, apply it to the trunk, and |
| 27 | commit directly, not merge. This keeps the history cleaner. | 27 | commit directly, not merge. This keeps the history cleaner. |
| 28 | 28 | ||
| 29 | In general, when working on some feature in a separate branch, it is | ||
| 30 | preferable not to merge from trunk until you are done with the | ||
| 31 | feature. Unless you really need some change that was done on the | ||
| 32 | trunk while you were developing on the branch, you don't really need | ||
| 33 | those merges; just merge once, when you are done with the feature, and | ||
| 34 | Bazaar will take care of the rest. Bazaar is much better in this than | ||
| 35 | CVS, so interim merges are unnecessary. | ||
| 36 | |||
| 29 | Or use shelves; or rebase; or do something else. See the thread for | 37 | Or use shelves; or rebase; or do something else. See the thread for |
| 30 | yet another fun excursion into the exciting world of version control. | 38 | yet another fun excursion into the exciting world of version control. |
| 31 | 39 | ||