Re: Syncing Gnus and Emacs repositories

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > From: Kenichi Handa <address@hidden>
 > > CC: address@hidden, address@hidden
 > > Date: Mon, 18 Jun 2007 08:07:28 +0900
 > > 
 > > No.  I asked to merge unicode-2 into the trunk, but as it
 > > was not accepted, I asked not to make heavy changes to the
 > > trunk unless one takes care of emacs-unicode-2 branch too.
 > 
 > So in that case, making such changes in the Unicode branch directly,
 > as I suggested, would be a good way of installing changes without
 > interfering with the future merge, right?

Assuming that those making changes in the Unicode branch are
thoroughly familiar with it, yes.  If (as seems more likely), most
developers will split their attention three ways, between 22.x
bugfixes, permissible changes to the trunk, and blue-sky changes to
the emacs-unicode-2 branch, then people will care most about their own
blue-sky changes, and know very little about regressions in
emacs-unicode-2, until pointed out to them.  But emacs-unicode-2 will
be a branch, still, and will not get so much testing.  The risk of
regression in emacs-unicode-2 work seems substantial.  If I were
Handa-san, I would resist opening that branch to commits related to
work that could be done in non-emacs-unicode-2 branches.

Also, David Kastrup is quite right about the deficiencies of CVS.
XEmacs did something similar to what is being proposed here.  Under
pressure from people who were not primarily interested in the 21.4
release, we branched in January 2001, pushing blue-sky projects off on
a branch, and keeping 21.4 on the trunk.  It immediately became clear
this was unsustainable due to the difficulty of using cvs annotate,
cvs diff, and cvs update -j with mainline on a CVS branch.  So in
April 2001, less than three months later, we transplanted the trunk
(starting from the fork) to a new release-21-4 branch, and the 21.5
branch back to the trunk, at fairly high cost in current usefulness of
annotate, diff and update -j.  However, with mainline on the branch,
that cost was increasing rapidly, while with mainline on the trunk,
the cost decreased to negligible by the end of summer 2001.  While in
the end we avoided total disaster, the rationalization effort was
unaccompanied by any net benefit whatsoever, in fact, there were net
costs both before and after the rationalization compared to doing it
right by putting mainline on the trunk as soon was the 21.4 feature
freeze was implemented.

Caveat: as of CVS 1.12 or so, the -r TAG:DATE option format is
available.  This might mitigate the very strong bias of CVS in favor
of comparisons with and merges to trunk.  However, because of the
structure of ,v files, there is no question that after a few hundred
commits work that involves both mainline and another branch will
become painfully inefficient.

N.B. Emacs's situation is somewhat different from XEmacs 21.4, as
people seem willing to accept an across-the-board freeze during the
release cycle.  However, given that the EMACS_22_BASE branch now
exists, IMO *all* large merges and other potentially destabilizing
changes should be done to the trunk where they will get maximum
testing; the only question is whether they should be synchronized to
events in Emacs 22 for some reason, or whether the trunk should be
opened now to merge of emacs-unicode-2 and so on, subject to
negotiation among the developers working on the trunk (ie, not
considering effects on Emacs 22).

Bottom line: The risks are high, the benefits are small.  I strongly
recommend against doing substantial work on a CVS branch, unless it
has a single theme and is explicitly aimed at a single merge to
mainline, then retirement.

If Richard sustains his veto of merging emacs-unicode-2 and other
potentially destabilizing work on the trunk, then, based on that
experience, I see only two practical choices.  (1) Accept that the
trunk will stay in feature slush for a while, and work on the
branch(es) that interest you in separate workspaces until permission
is given to merge to trunk.  (2) Switch to a distributed SCM like Arch
or git for cooperative work on merged workspaces, and use CVS only to
maintain continuity of communication with the rest of the world and
those whose current work is focused on the 22.x branch or features
admissible on the trunk in CVS.  (Subversion is not a panacea here.)