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