From: "Vincent Belaïche" <vincent.b.1@hotmail.fr>
To: emacs-devel@gnu.org
Subject: EMACS 24.2.50.1 crashing
Date: Sun, 28 Oct 2012 05:20:53 +0100 [thread overview]
Message-ID: <80sj8z5isa.fsf@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
Hello,
I am using a rather recent build from the trunk
GNU Emacs 24.2.50.1 (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.
VBR,
Vincent.
[-- Attachment #2: USING_CEDET_FROM_BZR --]
[-- Type: text/plain, Size: 13002 bytes --]
-*- mode: org -*-
* Goal
The goal of this document is twofold:
- describe a workflow that will produce a repository history like [[http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/zen.html][this one]]
- 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
contents.
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.
* Organization
The main repository is hosted at [[http://sourceforge.net/projects/cedet/][SourceForge]]. There, code is organized into
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
https://sourceforge.net/scm/?type=bzr&group_id=17886
You must login to see URLs for read/write acess
- SourceForge-specific information when using bazaar
https://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar
*NOTE*: It is very important to correctly set /whoami/
- Bazaar documentation
http://doc.bazaar.canonical.com
- The workflow adopted at Emacs
http://www.emacswiki.org/emacs/BzrForEmacsDevs
The current document is heavily based on this document, and you can refer to
it for more thorough descriptions and discussions on alternative simplified
workflows.
If you need an introduction on basic terminology and concepts, please read
these:
- http://wiki.bazaar.canonical.com/BzrForCVSUsers
- http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/core_concepts.html
** 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
documents:
- http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/organizing_branches.html
- http://www.emacswiki.org/emacs/BzrForEmacsDevs
*** Setting up the environment
First you will have to create a /shared repository/ to work on your machine:
#+BEGIN_SRC sh
export DEVHOME=~/Projects/ # suit to your taste
cd $DEVHOME
bzr init-repo cedet/
#+END_SRC
Next step is to create a mirror of the mainline (=code/trunk=), from which
all other branches will be derived:
#+BEGIN_SRC sh
bzr checkout bzr+ssh://USERNAME@cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk trunk
#+END_SRC
*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
commits:
#+BEGIN_SRC sh
mkdir -p ~/.bazaar/
echo "[$DEVHOME/cedet]" >> ~/.bazaar/locations.conf
echo "email = USERNAME <USERNAME@users.sourceforge.net>" >> ~/.bazaar.locations.conf
#+END_SRC
*NOTE*: If you do not have a SourceForge account you can use your name and
e-mail instead.
*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
easier.
#+BEGIN_SRC sh
cd $DEVHOME/cedet/
bzr branch trunk/ TASKNAME/
#+END_SRC
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' [[http://www.gnu.org/software/emacs/manual/html_node/emacs/Version-Control.html][Version 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 <his@mail.address>" 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:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/trunk
bzr update
#+END_SRC
**** 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:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/TASKNAME/
bzr merge ../trunk
<<resolve conflicts, test, ...>>
bzr commit -m "Merge from trunk"
#+END_SRC
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:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/TASKNAME/
bzr push bzr+ssh://USERNAME@cedet.bzr.sourceforge.net/bzrroot/cedet/code/TASKNAME
#+END_SRC
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:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/
bzr branch bzr+ssh://USERNAME@cedet.bzr.sourceforge.net/bzrroot/cedet/code/TASKNAME
#+END_SRC
And you can update its contents anytime with:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/TASKNAME/
bzr pull
#+END_SRC
**** 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:
#+BEGIN_SRC sh
ssh -t USERNAME,cedet@shell.sourceforge.net create
chmod -R g+w /home/scm_bzr/c/ce/cedet/code/TASKNAME/
#+END_SRC
Similarly, you can change the name of a branch and move it around with
simple file movement commands:
#+BEGIN_SRC sh
ssh -t USERNAME,cedet@shell.sourceforge.net create
mv /home/scm_bzr/c/ce/cedet/code/TASKNAME/ /home/scm_bzr/c/ce/cedet/code/NEW_TASKNAME/
#+END_SRC
*** 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.
#+BEGIN_SRC sh
bzr send -o TASKNAME-v1.txt
#+END_SRC
*** Merging into the mainline (merging into trunk)
Once the modifications are ready for integration into mainline, the steps
are:
#+BEGIN_SRC sh
cd $DEVHOME/cedet/TASKNAME/
bzr missing # see what we and others are missing
cd $DEVHOME/cedet/trunk/
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
#+END_SRC
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
bzr+ssh://USERNAME@cedet.bzr.sourceforge.net/bzrroot/cedet/code/TASKNAME=.
** 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.
[-- Attachment #3: Sans titre.PNG --]
[-- Type: image/png, Size: 157286 bytes --]
next reply other threads:[~2012-10-28 4:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-28 4:20 Vincent Belaïche [this message]
2012-10-28 17:28 ` EMACS 24.2.50.1 crashing Eli Zaretskii
2012-10-28 18:47 ` Glenn Morris
-- strict thread matches above, loose matches on Subject: below --
2012-10-28 12:53 Vincent Belaïche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80sj8z5isa.fsf@gmail.com \
--to=vincent.b.1@hotmail.fr \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.