http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
+The exception is, if you know that the change will be difficult to
+merge to the trunk (eg because the trunk code has changed a lot).
+In that case, it's helpful if you can apply the change to both trunk
+and branch yourself (when committing the branch change, indicate
+in the commit log that it should not be merged to the trunk; see below).
+
* 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.
+Indicate in the commit log that there is no need to merge the commit
+to the trunk. Anything that matches `bzrmerge-skip-regexp' will do;
+eg start 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
http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html
+* Installing changes from gnulib
+Some of the files in Emacs are copied from gnulib. To synchronize
+these files from the version of gnulib that you have checked out into
+a sibling directory of your branch, type "make sync-from-gnulib"; this
+will check out the latest version of gnulib if there is no sibling
+directory 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 file
+using "bzr add". After synchronizing from gnulib, do a "make" in the
+usual way.
+
+To change the set of gnulib modules, change the GNULIB_MODULES
+variable in the top-level Makefile.in, and then run:
+
+ ./config.status
+ make sync-from-gnulib
+ bzr status
+
+The last command will mention files that may need to be added using
+"bzr add". If you remove a gnulib module, or if a gnulib module
+removes a file, then remove the corresponding files by hand.
+
* 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.
+0) (This step is only necessary if using bzr older than 2.4.0.)
+Get the bzr changelog_merge plugin:
+
+cd ~/.bazaar/plugins
+bzr branch http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/trunk changelog_merge
+
+This plugin should make merging ChangeLogs smoother. It merges new
+entries to the top of the file, rather than trying to fit them in
+mid-way through. Newer versions of the plugin should also be able to
+deal with changes to *old* ChangeLog entries, that should not be
+floated to the head of the file (see launchpad#723968).
+
+It is included in bzr from 2.4.0 onwards, so remember to delete the
+copy in ~/.bazaar if you upgrade bzr.
+
+Maybe the default Emacs behavior without this plugin is better,
+though, it's not clear yet.
+
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
+The first time only, do this:
+cd .bzr/branch
+Add the following line to branch.conf:
+changelog_merge_files = ChangeLog
+
3) load admin/bzrmerge.el
4) M-x bzrmerge RET /path/to/emacs-23 RET
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.
+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.
+6) After resolving all conflicts, you might need to run the bzmerge
+command again if there are more revisions still to merge.
+
+Do not commit (or exit Emacs) until you have run bzrmerge to completion.
Before committing, check bzr status and bzr diff output.
+If you have run bzrmerge enough times, the "pending merge tip" in bzr
+status should be the last revision from the emacs-23 branch, and
+bzr status -v should show all the revisions you expect to merge.
+
+(Note that it will also show "skipped" revisions. This is expected,
+and is due to a technical limitation of bzr. The log data for those
+revisions gets merged, the actual changes themselves do not.
+http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html )
+
+In particular, check the ChangeLog entries (eg in case too many
+entries have been included or whitespace between entries needs fixing).
+bzrmerge tries to fix up the dates to today's date, but it only does
+this where there are conflicts. If you used the changelog_merge plugin,
+there won't be any conflicts, and (at time of writing) you will need
+to adjust dates by hand. In any case, if someone made multiple
+ChangeLog entries on different days in the branch, you may wish to
+collapse them all to a single entry for that author in the trunk
+(because in the trunk they all appear under the same date).
+Obviously, if there are multiple changes to the same file by different
+authors, don't break the logical ordering in doing this.
+
+Notes:
+
+1) A lot that was in tramp.el in emacs-23 has moved to tramp-sh.el in
+the trunk. If you end up with a conflict in tramp.el, the changes may
+need to go to tramp-sh.el instead. Remember to update the file name in
+the ChangeLog.
+
+2) If a file is modified in emacs-23, and deleted in the trunk, you
+get a "contents conflict". Assuming the changes don't need to be in
+the trunk at all, use `bzr resolve path/to/file --take-this' to keep the
+trunk version. Prior to bzr 2.2.3, this may fail. You can just
+delete the .OTHER etc files by hand and use bzr resolve path/to/file.
+
+3) Conflicts in autoload md5sums in comments. Strictly speaking, the
+right thing to do is merge everything else, resolve the conflict by
+choosing either the trunk or branch version, then run `make -C lisp
+autoloads' to update the md5sums to the correct trunk value before
+committing.
+
+* Re-adding a file that has been removed from the repository
+
+It's easy to get this wrong. Let's suppose you've done:
+
+bzr remove file; bzr commit
+
+and now, sometime later, you realize this was a mistake and file needs
+to be brought back. DON'T just do:
+
+bzr add file; bzr commit
+
+This restores file, but without its history (`bzr log file' will be
+very short). This is because file gets re-added with a new file-id
+(use `bzr file-id file' to see the id).
+
+Instead of adding the file, try:
+
+bzr revert -rN file; bzr commit
+
+where revision N+1 is the one where file was removed.
+
+You could also try `bzr add --file-ids-from', if you have a copy of
+another branch where file still exists.
+
+* Loggerhead
+
+Loggerhead is the bzr tool for viewing a repository over http (similar
+to ViewVC). The central version is at http://bzr.savannah.gnu.org/lh/emacs,
+but if you just like the way this interface presents data, then if
+you have your own copy of the repository, you can operate your own
+Loggerhead server in stand-alone mode, and so help to reduce the load
+on Savannah:
+
+ bzr branch lp:loggerhead ~/.bazaar/plugins/loggerhead
+ cd /path/to/emacs/bzr
+ bzr serve --http
+
+You may need to install some Python dependencies to get this command to work.
+For example, on RHEL6 I needed:
+
+ yum install python-paste python-simplejson
+ yum --enablerepo=epel install python-simpletal
-Note that ChangeLog entries are automatically merged to the top with
-today's date, but you still might want to check them to see that too
-much is not being included.
+Then point your web-browser to http://127.0.0.1:8080/ .