SiteMap Search ElispArea HowTo Glossary RecentChanges News Problems Suggestions
Jordan, Independence Day, Argentina, National Day

the megapatch problem

The megapatch problem

Ben Wing is known for submitting and committing huge patches that combine several independent changes and touch scores of files in dozens of places each. Naturally, other developers grumble about the annoyance of keeping up and the serious problem of dealing with CVS conflicts, many of which are spurious but all require careful attention. But this is rather a medium-painful symptom of a bigger problem, which is the total lack of support in CVS for multiple, long-lived, regularly synched (with trunk and with each other) branches.

XEmacs is organized as a distributed project. People work on what they want to work on, and integrate when they’re ready. Sure, we’ve had success with a number of projects where the work-in-progress was integrated into the mainline under #ifdefs, such as the MINIMAL_TAGBITS work that gave us 31-bit integers (AFAIK even GNU Emacs 21.4 has at best 28 bits), the portable dumper (which gave us a three-line “port” to Mac OS X with X11 as the display), and the current KKCC work on garbage collection. But it’s still a headache to deal with synching to the mainline when things are moving fast, and people with controversial projects may need to work outside of the mainline for a while. Not to mention that I think we were much too lenient in 21.2 (the devel branch that forked into 21.4 and 21.5—there never was a 21.3 and never will be one). Several developers took advantage of the ease of getting features into the mainline to commit their work as they went along, then went AWOL at various stages of completion, leaving bugs and ugliness for others to fix. Really, these folks should be working on branches—but I have to admit that CVS basically makes that untenable.

I think the solution here is local use of “advanced/distributed revision control systems” of which the Arch family (larch, tla, ArX, baz, and bzr) has gotten a lot of play, including use for the official repository of SXEmacs, but Darcs, Monotone, PRCS, and several others are well-known. We also have a new candidate in git/Cogito, Linus Torvalds’s replacement for BitKeeper in the Linux workflow, or its alternative Mercurial. Unlike SXEmacs, I don’t want to move on to keeping the central repository in Arch, not yet. SXEmacs basically said, “XEmacs 21.4 is one hell of a good editor. Let’s get a jump on the QA work by starting from that rock-solid base.” But (last I looked) SXEmacs’s repository has no history before the fork point! That won’t be acceptable in the XEmacs mainline. We do need to look back to at least 21.5.0 to understand some problems in 21.5.22. But I have had no success in converting the whole XEmacs repository to Arch or Darcs, and I suspect that cvs2svn will be no more successful (in part because of some brain-damaged manipulation of our CVS repository at various times since it was created in December 1996). Even the conservative approach of using Subversion is unlikely to be straightforward.

Personally, I’ve put all of my workspaces under Darcs control, and it makes merges easy, not least because it’s interactive and patch-oriented. OOTB, it’s definitely better than Arch (larch/ArX/tla/baz) for my purpose. (bzr, on the other hand, is consciously picking up many of the features that Darcs and other systems have shown to be best practices.) Sure, all the Emacs MUAs support piping the message to patch, but it’s not the same. Basically, moving patches around using Darcs is as easy and natural as using Emacs to edit the file (except that I wish I could be using a programmable Emacs interface to Darcs’s interactive features). Darcs has a few problems, specifically with ChangeLogs. So what else is new? All revision control systems have problems with ChangeLogs (which is why all revision control systems, even CVS, make it as easy as possible to keep your logs in the repository metadata rather than in a file under revision control). I believe this reflects a fundamental misunderstanding of the nature of the problem. David Roundy’s theory of patches comes close to addressing the right issues, I think, but even that isn’t radical enough. Hint: especially not if you’re an Emacs fan! More about that later (possibly elsewhere), though.

Arch has its fans, especially in our sister projects GNU Emacs and SXEmacs. Use of Arch to manage branches and then push to Savannah seems to work for several core Emacs developers. But the rest of the world seems to be moving away from Arch to Darcs and Bazaar-NG.

Unfortunately, I’ve discovered that Darcs doesn’t like ChangeLogs?, CHANGES-beta, version.sh, or any other file that regularly gets updated in the same place, unless it owns them. But that’s not the plan; CVS owns them for now.


There was succesful import of Linux kernel history from BitKeeper and from CVS into git: see Linux: Importing The Kernel Into git, Merging and Linux: Entire 2.6 Source Tree Imported Into Git articles on Kerneltrap.


Back to StephenTurnbull XEmacsDesiderata