view admin/notes/bzr @ 109391:a4e57fa6eb3f

Fix menu bar activation with click for Motif/Lesstif. * src/xdisp.c (pending_menu_activation): Remove extern declaration. (prepare_menu_bars): Remove setting of pending_menu_activation. * src/xmenu.c (pending_menu_activation): Remove. (x_activate_menubar): Set popup_activated_flag for Xt also. Remove setting of pending_menu_activation. (set_frame_menubar): Remove check of pending_menu_activation. Declare menubar_size before code. Correct spelling in comment. * src/xterm.c (xm_scroll_callback, x_process_timeouts): K&R => prototype. (SET_SAVED_KEY_EVENT): Remove (not used). (SET_SAVED_MENU_EVENT): Rename to SET_SAVED_BUTTON_EVENT and remove size parameter. (handle_one_xevent): Check popup_activated () for menu for Xt also. Remove #ifdef USE_GTK around finish = X_EVENT_DROP. Remove #ifdef USE_MOTIF code that did SET_SAVED_BUTTON_EVENT for ButtonRelease.

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

* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-23").
Label the commit as a backport, e.g. by starting the commit message with
"Backport:".  This is helpful for the person merging the release branch
to the trunk.

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.

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.

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