* lisp/electric.el (electric-indent-post-self-insert-function):

[bpt/emacs.git] / admin / notes / bzr

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.

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.

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

* 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.

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.

Before committing, check bzr status and bzr diff output.

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.