2010-05-18 02:52:21 +00:00
|
|
|
NOTES ON COMMITTING TO EMACS'S BAZAAR REPO -*- outline -*-
|
|
|
|
|
|
|
|
|
|
* Install changes only on one branch, let them get merged elsewhere if needed.
|
|
|
|
|
In particular, install bug-fixes only on the release branch (if there
|
|
|
|
|
is one) and let them get synced to the trunk; do not install them by
|
|
|
|
|
hand on the trunk as well. E.g. if there is an active "emacs-23" branch
|
|
|
|
|
and you have a bug-fix appropriate for the next Emacs-23.x release,
|
|
|
|
|
install it only on the emacs-23 branch, not on the trunk as well.
|
|
|
|
|
|
|
|
|
|
Installing things manually into more than one branch makes merges more
|
|
|
|
|
difficult.
|
|
|
|
|
|
|
|
|
|
http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
|
|
|
|
|
|
|
|
|
|
* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23").
|
|
|
|
|
Label the commit as a backport, e.g. by starting the commit message with
|
|
|
|
|
"Backport:". This is helpful for the person merging the release branch
|
|
|
|
|
to the trunk.
|
|
|
|
|
|
|
|
|
|
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
|
|
|
|
|
|
|
|
|
|
* Installing changes from your personal branches.
|
|
|
|
|
If your branch has only a single commit, or many different real
|
|
|
|
|
commits, it is fine to do a merge. If your branch has only a very
|
|
|
|
|
small number of "real" commits, but several "merge from trunks", it is
|
|
|
|
|
preferred that you take your branch's diff, apply it to the trunk, and
|
|
|
|
|
commit directly, not merge. This keeps the history cleaner.
|
|
|
|
|
|
2010-05-18 07:38:35 +00:00
|
|
|
In general, when working on some feature in a separate branch, it is
|
|
|
|
|
preferable not to merge from trunk until you are done with the
|
|
|
|
|
feature. Unless you really need some change that was done on the
|
|
|
|
|
trunk while you were developing on the branch, you don't really need
|
|
|
|
|
those merges; just merge once, when you are done with the feature, and
|
|
|
|
|
Bazaar will take care of the rest. Bazaar is much better in this than
|
|
|
|
|
CVS, so interim merges are unnecessary.
|
|
|
|
|
|
2010-05-18 02:52:21 +00:00
|
|
|
Or use shelves; or rebase; or do something else. See the thread for
|
|
|
|
|
yet another fun excursion into the exciting world of version control.
|
|
|
|
|
|
|
|
|
|
http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
|
2011-01-15 21:47:46 +00:00
|
|
|
|
|
|
|
|
* How to merge changes from emacs-23 to trunk
|
|
|
|
|
|
|
|
|
|
The following description uses bound branches, presumably it works in
|
|
|
|
|
a similar way with unbound ones.
|
|
|
|
|
|
|
|
|
|
1) Get clean, up-to-date copies of the emacs-23 and trunk branches.
|
|
|
|
|
Check for any uncommitted changes with bzr status.
|
|
|
|
|
|
|
|
|
|
2) M-x cd /path/to/trunk
|
|
|
|
|
|
|
|
|
|
3) load admin/bzrmerge.el
|
|
|
|
|
|
|
|
|
|
4) M-x bzrmerge RET /path/to/emacs-23 RET
|
|
|
|
|
|
|
|
|
|
It will prompt about revisions that should be skipped, based on the
|
|
|
|
|
regexp in bzrmerge-missing. If there are more revisions that you know
|
|
|
|
|
need skipping, you'll have to do that by hand.
|
|
|
|
|
|
|
|
|
|
5) It will stop if there are any conflicts. Resolve them.
|
|
|
|
|
Using smerge-mode, there are menu items to skip to the next conflict,
|
|
|
|
|
and to take either the trunk, branch, or both copies.
|
|
|
|
|
|
|
|
|
|
6) After resolving all conflicts, you might need to run the command
|
|
|
|
|
again if there are more revisions still to merge.
|
|
|
|
|
You can commit either before you do this (eg if you had a lot of
|
|
|
|
|
conflicts to resolve and don't want to get confused), or refrain from
|
|
|
|
|
committing until bzrmerge has merged all revisions.
|
|
|
|
|
|
