Re: Ways of keeping Emacs 22 and external projects in sync

[Ralf Angeli <angeli@caeruleus.net>]

* Michael Olson (2007-01-01) writes:

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

AFAIK changes to Gnus files in Emacs' repository will be transferred
automatically via Miles' Arch repositories to Gnus' stable branch.
I'm not sure how changes relevant to the trunk are moved there.

> 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.
[...]
> 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.
[...]
> 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
> ===

The scripts look identical.  Is that correct?

> * Syncing changes
>
> When there are some changes that need to be propagated to Emacs 22, I

So you are updating ERC in Emacs not on a release-by-release basis,
but rather when some important changes need to be propagated?  Do you
apply a tag in that case in order to identify the file revisions if
somebody has a bug report or support request referring to the ERC
version in Emacs or do you just use the files in Emacs directly for
testing and debugging?

> 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).

Do you regularly synch from Emacs or just when you are about to synch
to Emacs?

My idea for RefTeX would have been that a synch from Emacs to RefTeX
is done regulary, but directly instead of using an intermediate
repository.

> 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).

That reminds me: When you are synching from Emacs to ERC (and vice
versa) the ChangeLog file is probably handled the same way Lisp files
are.  Because log entries of changes to RefTeX in Emacs currently end
up in lisp/ChangeLog we'd need a separate ChangeLog file for RefTeX
for this to work.

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

As Savannah supports Arch repositories now it should be no problem to
maintain RefTeX in such a repository.  What I would be missing with
Arch would be something like PCL-CVS and the web interface like
Savannah provides it for CVS repositories.

-- 
Ralf