This document describes some workflows by which a casual contributor can follow Emacs development, without having the full developer setup.
If you want a simple CVS-style workflow, please follow BzrQuickStartForEmacsDevs and we still recommend that even casual developers eventually migrate to the the regular developer’s workflow described at BzrForEmacsDevs. If you have time to set that up, please do so now instead of reading this page; it offers a superset of what this page describes, and is more standard (therefore better supported).
Nevertheless, if you just need a quick-and-easy way to follow bleeding edge Emacs, or to make a one-time patch contribution, etc, then this page may help.
If you just want to run bleeding-edge code (perhaps so you can report bugs against the latest development sources), and do not expect to make code changes to Emacs, then you can save a little bit of time and space by using a stacked branch:
cd /home/jrandom/projects # or wherever bzr branch --stacked bzr://bzr.savannah.gnu.org/emacs/trunk emacs-trunk
bzr+ssh:// instead of
bzr:// if you have write access.)
Now you can build, test, install, and run Emacs in this directory in the usual way. If you want to update the checkout, you just do
cd /home/jrandom/projects/emacs-trunk bzr pull
bzr pull will fail if you have made any changes to version-controlled files.
bzr pull failed because you “had an itch”, and made some changes in your
emacs-trunk stacked branch. You may as well send your improvement upstream.
Write up a ChangeLog entry for your change. Now
bzr commit -m "Describe my wonderful patch."
Then follow the instructions for BzrForEmacsDevs#SendABundle to submit your changes for review. From now on, until your code is merged, you cannot use
bzr pull. You must merge, instead:
bzr merge bzr commit -m "Merge from upstream master."
The merge may fail due to a change that conflicts with yours. You’ll need to fix the problem, then
bzr resolve -m file-you-changed ... # Mark these conflicts as resolved. bzr commit -m "Merge from upstream master."
You will have to continue merging in this way until you code is merged.
We very rarely merge code like that, so don’t expect this workflow to work the way it’s described. – Stefan Monnier, Emacs Maintainer
But really, if you find yourself making one code change to Emacs, you’ll probably make more, so you should just take the time set to yourself up in the way described for BzrForEmacsDevs. Then you can follow the workflows described there (i.e., create a repository and mirror branch), and do:
cd /$DEVHOME/emacs bzr branch /home/jrandom/projects/emacs-trunk my-hacks cd my-hacks bzr merge --remember ../trunk rm -rf /home/jrandom/projects/emacs-trunk # optional
which updates your
my-hacks branch with changes from upstream, and sets the parent of the my-hacks branch to your
trunk mirror. After that you can simply follow the workflows recommended above for BzrForEmacsDevs (including submitting your patch by BzrForEmacsDevs#SendABundle!) Happy hacking!