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 thereis one) and let them get synced to the trunk; do not install them byhand on the trunk as well. E.g. if there is an active "emacs-23" branchand 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 moredifficult.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 branchto 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 realcommits, it is fine to do a merge. If your branch has only a verysmall number of "real" commits, but several "merge from trunks", it ispreferred that you take your branch's diff, apply it to the trunk, andcommit directly, not merge. This keeps the history cleaner.In general, when working on some feature in a separate branch, it ispreferable not to merge from trunk until you are done with thefeature. Unless you really need some change that was done on thetrunk while you were developing on the branch, you don't really needthose merges; just merge once, when you are done with the feature, andBazaar will take care of the rest. Bazaar is much better in this thanCVS, so interim merges are unnecessary.Or use shelves; or rebase; or do something else. See the thread foryet another fun excursion into the exciting world of version control.http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html* Installing changes from gnulibSome of the files in Emacs are copied from gnulib. To synchronizethese files from the version of gnulib that you have checked out intoa sibling directory of your branch, type "make sync-from-gnulib"; thiswill check out the latest version of gnulib if there is no siblingdirectory already. It is a good idea to run "bzr status" afterwards,so that if a gnulib module added a file, you can record the new fileusing "bzr add". After synchronizing from gnulib, do a "make" in theusual way.To change the set of gnulib modules, change the GNULIB_MODULESvariable in the top-level Makefile.in, and then run: ./config.status make sync-from-gnulib bzr statusThe last command will mention files that may need to be added using"bzr add". If you remove a gnulib module, or if a gnulib moduleremoves a file, then remove the corresponding files by hand.* How to merge changes from emacs-23 to trunkThe following description uses bound branches, presumably it works ina 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/trunk3) load admin/bzrmerge.el4) M-x bzrmerge RET /path/to/emacs-23 RETIt will prompt about revisions that should be skipped, based on theregexp in bzrmerge-missing. If there are more revisions that you knowneed 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 commandagain if there are more revisions still to merge.Do not commit (or exit Emacs) until bzrmerge has merged all revisions!Before committing, check bzr status and bzr diff output.Note that ChangeLog entries are automatically merged to the top withtoday's date, but you still might want to check them to see that toomuch is not being included.Notes:1) A lot that was in tramp.el in emacs-23 has moved to tramp-sh.el inthe trunk. If you end up with a conflict in tramp.el, the changes mayneed to go to tramp-sh.el instead. Remember to update the file name inthe ChangeLog.2) If a file is modified in emacs-23, and deleted in the trunk, youget a "contents conflict". Assuming the changes don't need to be inthe trunk at all, use `bzr resolve path/to/file --take-this' to keep thetrunk version. Prior to bzr 2.2.3, this may fail. You can justdelete the .OTHER etc files by hand and use bzr resolve path/to/file.