Emacs uses Git as its version control system since 2014-11-12. This page is therefore out of date and mainly of historical interest.

Refer instead to:
* [EmacsFromGit]
* [GitForEmacsDevs]
* [GitQuickStartForEmacsDevs]

----

== Bazaar Workflows for Casual Developers ==

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.

[:BleedingEdgeBuilds]
=== How To Follow Bleeding-Edge Emacs ===

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

(Use ##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

Note that ##bzr pull## /will fail/ if you have made /any/ changes to version-controlled files.

[:PatchContributors]
=== How One-Time Patch Contributors Should Use Bazaar ===

Oops --- ##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.  

      cd /home/jrandom/projects/emacs-trunk

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.

[new]
We very rarely merge code like that, so don't expect this workflow to work the way it's described. -- Stefan Monnier, Emacs Maintainer

[new]
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!