2:23 a.m.
>>>> "Eric" == Eric Knauel
<knauel(a)informatik.uni-tuebingen.de> writes:
Eric> Ok, I probably misunderstood. I just received the
Eric> impression, that my patches to the Xft branch would not be
Eric> welcome for some reason.
Patches are welcome to the branch. I've been asking for an Xft branch
for more than a year; I just decided that OK, I'll just do it.
Eric> So, what do I have to do to get commit access to the branch?
Send an SSH public key and a preferred nickname to
cvs-manager(a)xemacs.org and one of us will add it (with approval of the
Review Board, but that should be no problem). As nicknames either
your first or last name is currently open, but you may pick another.
Also, we will make an ＠xemacs.org address for you if you don't already
have one. The canonical one will be eric.knauel(a)xemacs.org, but you
can have a couple of nicknames as well. If you prefer to receive mail
via the alias at an address other than the one in your "From" header,
please indicate that as well.
The purpose of the mail address is so that XEmacs people can contact
you without having to look up your current address. You don't need to
use it at all otherwise, and unless you do, it shouldn't "leak" out
(and attract spam). We do appreciate the advertising if you use it.
It's probably convenient to have the CVS nickname as one of your mail
nicknames.
> local repository for the advanced system. Even if things work
> out that we can share the sjt-xft branch all the way to
> integration, it makes a lot of operations easier, and can be
> essential if whoever is handling "synch-to-mainline" flakes out
> for a month.
Eric> Sure, if it makes things easier! However, I'm not sure if I
Eric> understood that completely: which merges are you referring
Eric> to?
mainline =+========+======+======+=>
\ | | A
V V V /
xft +----->+----->+----+
This kind of pattern is managable with CVS _if_ all the '+' nodes on
the mainline are tagged. Typically, however, several problems arise.
(1) ChangeLogs frequently cause conflicts because with all changes
occurring at the top of the file, the likelihood of simultaneous
changes on branch and mainline is very high.
(2) Often you will either independently patch a particular bug also
fixed in the mainline, or just "cherrypick" a single patch for it
off the mainline. On the next update, you get a conflict there.
(3) If you fix something on xft, and send the patch on to the
mainline, you will get a conflict there on future updates.
(4) If I'm doing the synch to mainline, but disappear for a month, you
may decide to synch it yourself in your workspace. If it turns
out we were working on synching simultaneously, one of us is going
to have to abandon that workspace. If there are other important
changes there, it's messy and tedious to winkle them out as a
separate patch. So you are dependent for synchs on my schedule.
All of these occur because CVS doesn't have any notion of "distance"
between two revisions, and doesn't understand the idea that a
_sequence_ of patches may be applied. The longer a branch lives, the
more frequent the spurious conflicts become.
The "advanced" systems do understand the idea of sequence of patches,
and even the idea of subsequences. darcs will even pick apart a patch
into hunks and rearrange them to minimize conflicts. darcs also has a
"global rename" operator. arch gives the developer more control over
how patch applications (merges) are done. Both automatically detect
and avoid "spurious" conflicts due to previously applied patches. I
don't yet have an opinion about which approach is better than the
other, but both are far better than CVS for working on a long-lived
branch.
Working with _multiple_ related branches in CVS is impractical, but
both arch and darcs handle this almost as easily as the simple branch
shown above. For example, suppose you like my "face" work and I like
your "menu" work, but you insist on UTF-8 for actual redisplay of Mule
characters, while I want UTF-16. Both arch and darcs make the
following pattern almost as easy as the simple branch.
mainline =+===============+==+====+======+=>
\ 2: :3 ^ ^
\ V : /5 /
menu \ +--+--+--＠--+ /6
\ / ^ : :4 /
+->+ :1 :3 : /
\ : V V /
face +--+-----+--+--+
Patch 1: you grab an early version of my face code.
Merge 2: you update to mainline.
Merge 3: we both synchronize to mainline.
Patch 4: I grab the final version of your menu code.
Merge 5: you integrate your branch to mainline.
Merge 6: I integrate my branch to mainline.
With an advanced system, all conflicts that arise are "real". Ie, you
and I independently changed the same code. For example when I merge
"face" to mainline, you've already merged your UTF-8 display code, and
we will have to decide UTF-8 vs. UTF-16 once and for all. The
advantages are (1) that we can postpone the decision until we have
experience with both schemes, and (2) the advanced systems provide
"undo" operations so we can back out a subset of your changes and
merge in mine fairly easily if that seems appropriate.
CVS can't handle this pattern at all, without extremely rigorous
tagging discipline (basically, you'd have to tag _every_ commit, and
keep separate records of the patch content for each tag). subversion
apparently has problems with it, too. The problem is that since they
don't understand (sub)sequences of patches, on merge 5, you'll get
conflicts from merges 2 and 3 which are already in mainline, on patch
4, I will get conflicts from patch 1 (which originated in my branch)
and merge 3 (which you and I independently got from mainline), and
merge 6 is just hopelessly complex, especially if we decide I was
"right" about UTF-16 and need to back out your merged code, but just
the UTF-8 redisplay part. Basically, that change will have to be made
entirely by hand.
For CVS, Ben has documented both the kind of branch-and-merge pattern
that can be used with CVS and a "homemade" global rename operator in
the XEmacs Internals manual.
Speaking of manuals, apparently there's some problem with the package
itself, so you can't just grab it with M-x list-packages yet, but my
Texinfo version of the fontconfig manpage (with pretty substantial
additions) is now in XEmacs CVS in the "general-docs" module. You can
just build it with makeinfo and drop it in your INFOPATH somewhere if
the package isn't available yet.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.