bzr 8.47 KB
Newer Older
Glenn Morris's avatar
Glenn Morris committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14
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

15 16 17 18 19 20
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).

Glenn Morris's avatar
Glenn Morris committed
21
* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23").
22 23 24 25
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.
Glenn Morris's avatar
Glenn Morris committed
26 27 28 29 30 31 32 33 34 35

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.

36 37 38 39 40 41 42 43
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.

Glenn Morris's avatar
Glenn Morris committed
44 45 46 47
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
48

49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
* 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.

70 71 72 73 74
* 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.

75 76
0) (This step is only necessary if using bzr older than 2.4.0.)
Get the bzr changelog_merge plugin:
77 78

cd ~/.bazaar/plugins
79 80 81 82 83 84 85 86 87 88
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.
89

90 91
Maybe the default Emacs behavior without this plugin is better,
though, it's not clear yet.
92

93 94 95 96 97
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

98 99 100 101 102
The first time only, do this:
cd .bzr/branch
Add the following line to branch.conf:
changelog_merge_files = ChangeLog

103 104 105 106 107 108 109 110
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.

111
5) It will stop if there are any conflicts.  Resolve them.
112 113 114
Using smerge-mode, there are menu items to skip to the next conflict,
and to take either the trunk, branch, or both copies.

115 116 117
6) After resolving all conflicts, you might need to run the bzmerge
command again if there are more revisions still to merge.

118
Do not commit (or exit Emacs) until you have run bzrmerge to completion.
119

120
Before committing, check bzr status and bzr diff output.
121 122 123
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.
124

125 126 127 128 129
(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 )

130 131 132 133 134
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
135 136 137 138
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).
139 140
Obviously, if there are multiple changes to the same file by different
authors, don't break the logical ordering in doing this.
141 142 143 144 145 146 147 148 149 150 151 152 153

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.
154 155 156

3) Conflicts in autoload md5sums in comments.  Strictly speaking, the
right thing to do is merge everything else, resolve the conflict by
157
choosing either the trunk or branch version, then run `make -C lisp
158 159
autoloads' to update the md5sums to the correct trunk value before
committing.
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175

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

Paul Eggert's avatar
Paul Eggert committed
176
Instead of adding the file, try:
177 178 179 180 181 182 183

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.
184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204

* 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

Then point your web-browser to http://127.0.0.1:8080/ .