Ways of keeping Emacs 22 and external projects in sync (was: CVS repository synchronization for RefTeX)

[Michael Olson]

Ralf Angeli <address@hidden> writes:

> * Giorgos Keramidas (2006-12-31) writes:
>
>> The people who currently maintain cc-mode and Gnus may have useful
>> feedback, regarding the tools they use for the job.  Do you think
>> it's a good idea to ask them and see what they have to say about
>> the best way to merge RefTeX source-drops with the CVS tree of
>> Emacs and keep merging updates, as they are committed to a separate
>> RefTeX repository?
>
> Well, I was hoping for some of them to chip into this thread.

I guess I'll chip in with how I manage to keep the development version
of ERC synced with that included with Emacs 22.  Gnus does it slightly
different than I do, because they merge directly to Emacs 22, rather
than using an intermediary branch like I do.

I use GNU Arch to maintain ERC.  Among the various branches are these:

erc--main--0 :: Where development happens

erc--rel--5.1 :: Where the currently previous major release (5.1) gets
  updated when it is time to prepare a minor release.

erc--emacs--22 :: The branch which is used to sync to and from the
  version in Emacs 22.

emacs--devo--0 :: The equivalent of CVS HEAD for Emacs in Arch, kept
  in sync by Miles Bader.

* Preparation

When preparing the Emacs 22 version of ERC for the first time, I added
explicit Arch tags to all of the files which would be included with
Emacs 22.  Namely: all .el files that don't depend on anything outside
of the Emacs source tree, NEWS (renamed etc/ERC-NEWS in Emacs 22),
ChangeLog, and the manual.  This way, even if the files are in
different directories, Arch can sort them out.

I then set up a couple of scripts (in a scripts/ directory that only
exists in the erc--emacs--22 branch) that help me sync to and from the
Emacs 22 source tree.

common.defs:
===
# Common definitions for syncing ERC             -*- Shell-script -*-

EMACS=~/proj/emacs/emacs
ETC=$EMACS/etc
LISP=$EMACS/lisp
MAN=$EMACS/man
===

sync-from-emacs:
===
#!/bin/bash

# Load common definitions
. scripts/common.defs

(cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
cp $ETC/ERC-NEWS etc/
cp $MAN/erc.texi man/
rm -f *.elc
===

sync-to-emacs:
===
#!/bin/bash

# Load common definitions
. scripts/common.defs

(cd $LISP/erc && find . -maxdepth 1 -mindepth 1 -type f -exec cp {} $OLDPWD \;)
cp $ETC/ERC-NEWS etc/
cp $MAN/erc.texi man/
rm -f *.elc
===

* Syncing changes

When there are some changes that need to be propagated to Emacs 22, I
first check emacs--devo--0 to see if someone changed things on the
Emacs side, by running ./scripts/sync-from-emacs.  If anything is
different than the current contents of erc--emacs--22, I immediately
check them in (to erc--emacs--22).

Then, I apply the necessary changes from erc--main--0.  Once all of
the conflicts have been resolved, I check in the code and run
./scripts/sync-to-emacs.  I then check to see whether Emacs still
compiles.  Depending on how large the changes are, I may test them.
Then, if changes were made to files outside of lisp/erc in the Emacs
tree, I add log entries for them in their respective directories.
That done, I check the changes in to emacs--devo--0 with a brief log
entry.

* Closing thoughts on related subjects

I think it is unrealistic to expect that large, active projects which
are included with Emacs 22 use the Emacs source tree for their main
development area.  It makes much more sense for such projects to just
merge in critical updates and new releases.  It also makes rapid
development easier, because operations on the revision control system
of choice take significantly more time on the entire Emacs tree as
compared to just the files of the individual project.

I also think it is a very bad idea for Emacs developers to mandate
checking in files individually.  It might make sense for work on the
core files in lisp/emacs-lisp/ or the top-level of lisp/, but a
significant percentage of changes made to the other lisp files involve
changing several files at once.  Separating log entries for commit
messages begins to become a burden.  For operations such as updating
an entire project, this would become very tedious (not to mention
unnecessary, because ChangeLog contains all the information that is
really needed).

With Arch, such changes are treated as a single change to the entire
project, rather than multiple separate changes to single files.  There
is no possibility (however remote) of changes to several files being
only partially applied, as long as Arch is the only version control
system involved.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Lisp, text markup, protocols -- Jabber: mwolson_at_hcoop.net
  /` |\ | | | Projects: Emacs, Muse, ERC, EMMS, Planner, ErBot, DVC
 |_] | \| |_| Reclaim your digital rights by eliminating DRM.
      See http://www.defectivebydesign.org/what_is_drm for details.

pgpH6O2WTn4Po.pgp
Description: PGP signature