[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EMACS 18.104.22.168 crashing
EMACS 22.214.171.124 crashing
Sun, 28 Oct 2012 05:20:53 +0100
I am using a rather recent build from the trunk
GNU Emacs 126.96.36.199 (i386-mingw-nt5.1.2600) of 2012-10-09 on CHOUNEK
and came on a funny crash --- attached PNG picture of the error message.
When I open some Org mode file USING_CEDET_FROM_BZR using Dired-X, and
opening in the same buffer the sub-directory where the file is, and
typing RET while the pointer in on the file to visit it, then I have the
crash. But if I directly visit it with C-x C-f, there is not any crash.
There isn't any crash also if I start EMACS with -Q in the command line
and follow the same procedure as the one causing the crash.
-*- mode: org -*-
The goal of this document is twofold:
- describe a workflow that will produce a repository history like
- concisely describe the bazaar commands necessary for such a workflow
The reason for such a workflow is that someone looking at the logs of the main
branches will directly see which features have been added, bugs fixed,
etc. Or, in other words, we should be able to use the log messages as the NEWS
This will not only make it nice and clear to traverse the log history, but
will also facilitate the task of managing changes and deciding which of them
must be published on each release. That is, it will be much easier for the
release managers to pick pre-arranged groups of closely related changes
instead of manually selecting changes one by one when releasing a new version.
The main repository is hosted at
[[http://sourceforge.net/projects/cedet/][SourceForge]]. There, code is
two main types of branches:
- =code/trunk= :: Main development branch, where new features, bug fixes,
etc. are merged into by developers.
- =code/cedet-<version>= :: Major release branches. These are managed only by
release managers, whose tasks consist of:
- Creating a new major release branch every time a new major release is
about to be produced.
- Tagging the =trunk= branch on every new major release.
- Cherry picking changes from =trunk= into the release branch, in order
to advance it into new minor releases.
- Tagging the release branch on every new minor release.
Any other branch is only temporarily available while a new complex feature or
bug fix is being collaboratively developed by many developers. Once the
development of such branch is considered stable, the branch might be deleted.
* The workflow in commands
First of all, the information sources:
- SourceForce repository URLs
You must login to see URLs for read/write acess
- SourceForge-specific information when using bazaar
*NOTE*: It is very important to correctly set /whoami/
- Bazaar documentation
- The workflow adopted at Emacs
The current document is heavily based on this document, and you can refer to
it for more thorough descriptions and discussions on alternative simplified
If you need an introduction on basic terminology and concepts, please read
** Developer workflow
The developer is assumed to develop new features and fix bugs by working on
separate (probably local) branches, that are later merged into the mainline
(the =code/trunk= branch on the CEDET repository).
This precise workflow is a tuned version of the workflows described on this
*** Setting up the environment
First you will have to create a /shared repository/ to work on your machine:
export DEVHOME=~/Projects/ # suit to your taste
bzr init-repo cedet/
Next step is to create a mirror of the mainline (=code/trunk=), from which
all other branches will be derived:
bzr checkout bzr+ssh://address@hidden/bzrroot/cedet/code/trunk trunk
*NOTE*: Here /USERNAME/ stands for your SourceForge username. If you do not
have commit access to the CEDET repositories you should use the read-only
URL instead: bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk
Finally, you have to tell bazaar the identity you want to use for your
mkdir -p ~/.bazaar/
echo "[$DEVHOME/cedet]" >> ~/.bazaar/locations.conf
echo "email = USERNAME <address@hidden>" >> ~/.bazaar.locations.conf
*NOTE*: If you do not have a SourceForge account you can use your name and
*NOTE*: Setting the information on =~/.bazaar/locations.conf= is probably
much more convenient than using the straightforward =bzr whoami --branch
"..."= command on *every* new branch, or using =bzr whoami "..."= to set
the information *globally*.
*** Creating a task branch
Once merged back into mainline, all changes added to this branch will appear
grouped under a single log entry (although separate changes are still
available), which makes the review and release management process much
bzr branch trunk/ TASKNAME/
Here, /TASKNAME/ could be something like the ticket number of the bug that
is being fixed, or a short descriptive name of a new feature.
*** Working in a task branch
This contains the typical development loop.
**** Making changes
Do not fear committing mutiple small changes if they are conceptually
different, even if they are not complete when separate. Your commits will
not be seen by others until you tell bazaar to do so.
On each commit, you would typically:
- =bzr status= :::
Check the current state of your local branch.
- =bzr add ...= :::
Add new files or directories to the repository.
- =bzr remove ...= :::
Remove files or directories from the repository.
- =bzr mv ...= :::
Move files or directories on the repository. Moved (renamed) files or
directories will still retain their full history.
- =bzr revert ...= :::
Undo uncommitted changes.
- =bzr shelve/unshelve ...= :::
Temporally undo/redo uncommitted changes.
- =bzr commit ...= :::
Commit changes on current branch.
If given the =-m "..."= flag, the given one-line message will be used as
the commit message; otherwise, your default editor will be fired up for
you to fill-in the message.
*NOTE*: You can use Emacs'
Control]] package to simplify the task
with a few simple keystrokes.
If you're committing patches contributed by other people, you
should use their names as authors by using the =--author=
switch, for example
=bzr commit --author "some guy <address@hidden>" somefile.el=
**** Refreshing your mirror of mainline (updating trunk)
The official mainline will change from time to time, so you should refresh
it whenever you want to work with the changes:
**** Merging the latest mainline into your branch (merging from trunk)
Changes on the mainline could conflict with changes you have added on your
local branch, or you might even want to use them. Thus, after updating
trunk you should merge its changes into your local branch:
bzr merge ../trunk
<<resolve conflicts, test, ...>>
bzr commit -m "Merge from trunk"
You can see the missing pieces before updating with =bzr missing
OTHER_BRANCH=, which will show you what you're missing from /OTHER_BRANCH/,
as well as what /OTHER_BRANCH/ is missing from you.
*NOTE*: You can use a directory instead of a remote URL, so that the
process will be much faster.
*** Publishing a task branch
As said, some tasks require collaboration from multiple developers, or a
thorough review from others. The easiest way to accomplish this is to
publish your branch.
If you have commit access on the CEDET repositories, you can simply:
bzr push bzr+ssh://address@hidden/bzrroot/cedet/code/TASKNAME
If you don't have commit access you can still publish branches on your user
space in SourceForge or Launchpad.
If you want to follow the development of a published task branch, you can:
bzr branch bzr+ssh://address@hidden/bzrroot/cedet/code/TASKNAME
And you can update its contents anytime with:
**** Changing repository permissions and reorganizing directories
When publishing a task branch, SourceForge is configured to give write
permissions (commit) only to the user puslishing the branch.
Once published, if you want othe users to be able to commit into it, you
must login into SF and change the filesystem permissions for the directory
holding the selected task branch:
ssh -t USERNAME,address@hidden create
chmod -R g+w /home/scm_bzr/c/ce/cedet/code/TASKNAME/
Similarly, you can change the name of a branch and move it around with
simple file movement commands:
ssh -t USERNAME,address@hidden create
*** Sending a bundle for review
Instead of publishing your branch, you can submit your changes for review
through e-mail, where others can look at your changes and decide if they are
suited to be merged into the mainline.
If it's not accepted, don't worry; you can still modify files, make some
more commits to your local branch and generate a new bundle to send.
bzr send -o TASKNAME-v1.txt
*** Merging into the mainline (merging into trunk)
Once the modifications are ready for integration into mainline, the steps
bzr missing # see what we and others are missing
bzr update # make sure we are up-to-date
bzr merge ../TASKNAME/
bzr status # optionally see what has changed
<<resolve conflicts, if any>>
bzr commit # immediately pushes changes
The most important note here is that the commit message in here will be the
only one displayed by default on the mainline log for all the changes of
/TASKNAME/ that you have done.
*NOTE*: You can still see all the "intermediate" commits inside every merge
with =bzr log -n0=.
*BIG NOTE*: It is very important to perform one separate merge for each
clearly different feature addition or fix of a ticket on the bug
tracker. Otherwise, if multiple of them are merged at once, they will
appear as a single entry on the "simplified" log, and it will be harder for
release managers to pick them up separately in case they need to.
*** After you've finished your task
You can simply remove the directory =$DEVHOME/cedet/TASKNAME/= and start
with a fresh new branch to develop other features.
If you had published the branch, you should also =bzr rmbranch
** Common workflow shortcuts
*** Performing quick fixes
Some feel that it is uncomfortable to create a new branch for every new
feature, specially when such a feature is just a trivial fix that can be
contained on a single commit.
As /trunk/ is a /checkout/ of mainline (as opposed to a /branch/), it can be
directly used for trivial changes.
The difference between a /checkout/ and a /branch/ is that the former
automatically (and atomically) performs a =push= operation immediately after
each =commit=, as well as it can be updated with =update= instead of =pull=.
The net result is that a /checkout/ provides a workflow very similar to
other well-known centralized version control systems.
*See also*: =bzr help branches=, =bzr help checkouts=.
** TODO Release manager workflow
How to handle merges into release branches.
* TODO Log messages
How merge log messages should be written. This should allow others to quickly
see which subsystem or feature the merge is about, as well as if it is an
enhancement or a bug fix.
Merge messages should probably *not* follow the usual ChangeLog style, but
provide a concise description on the first line and, if necessary, any
clarifications and/or explanations on the following lines.
Description: PNG image
- EMACS 188.8.131.52 crashing,
Vincent Belaïche <=