[Mailman-Developers] [lm@bitmover.com: Re: FW: Staging System - Requirements Meeting Recap]

[Barry A. Warsaw]

>>>>> "LM" == Larry McVoy <lm@bitmover.com> writes:

    LM> hey there, two things: (a) is mailman better than majordomo?

I still firmly believe so.  We had never ending problems with
Majordomo on python.org, which is why (more than the philosophical
discomfort :) we made a strong push to get Mailman in operational
shape.  I've since been able to completely wax Majordomo from my hard
drives :)

Yes, Mailman needs work.  But there are some really great hackers on
mailman-developers and I think we just need to structure the project
better so that those folks can contribute more directly, without the
frustration when the core 5 of us are busy with Real Work.

    LM> Oh, and you can update "sideways".  One developer can slurp in
    LM> the changes in a another developer's tree directly, without
    LM> going through the "master" or "shared" tree.  In CVS terms, I
    LM> don't have to go back to the master repository, I can talk
    LM> directly to you.  The hierarchical nature of the system is
    LM> strictly a convention thing, you can resync from anywhere to
    LM> anywhere.

This really fires me up.  I would love to have Mailman's doco team
announce "hey, we've got a new revision, please sync with our
repository to check it out".  Meanwhile the archivists say "we've got
the new search engine ready for those who'd like to take a look".  So
then at some point I get an email saying that there's been enough
testing and people are feeling confident about the changes.  Until
then, maybe I don't even look at the stuff, and only suck it into the
master when there's been enough of that sideways development to make
things stable.  If I got vision right, that's exactly what I'm looking
for

    LM> with the idea being that the ChangeSet comments should be the
    LM> idea or concept you just did, while the per file comments are
    LM> implementation details.

Another very cool idea, because this is exactly how I'd like to work.
Currently I put both levels of detail into the individual file log
msgs, but I'd rather do it this way.  Is there an equivalent of citool
for Emacs?

    >> h.. Change Logs

    LM> You get these for free, it's the ChangeSet comment history.

One important thing for GNU projects (although I've been lax about it)
is the ability to generate GNU ChangeLogs.  Emacs has tools for
extracting this info out of RCS/CVS log msgs.  It would be nice to
have the same capability with BK.  If there are aliases for "cvs log"
then it might be a no-brainer.

    LM> We do this better than anyone.  Period.  Everyone else screws
    LM> up your history.  Here's how: you have two developers A and B.
    LM> They both do CVS update and have the same tree.  They both
    LM> modify file foo.c.  A checks in first, so B "lost the race"
    LM> and has to merge.  What CVS will check in is not B's changes,
    LM> it's B's changes plus whatever B had to do to merge.  That is
    LM> **two events** collapsed into one.  Why is this a big deal?
    LM> Undo.  Suppose B's stuff was good and A's stuff wasn't.  We
    LM> can reconstruct B's stuff without the merge.  CVS can't.  It
    LM> lost the information.

    LM> Look at http://www.bitkeeper.com/sccstool.html - what you are
    LM> seeing is the race and the merge.  I'm "lm" and "awc" is my
    LM> Windows guy.  We were working parallel and the graph that you
    LM> are seeing is the revision history after we merged.  1.89 is
    LM> the merge delta, 1.86.1.1 and 1.86.1.2 are my deltas.  If I
    LM> want to reconstruct just my work, I do an undo and tell it
    LM> which branch I want gone.

Um, drool.

    LM> . ChangeSets.  SCCS is a changeset engine, people just don't
    LM> know it.  What that means is that I can edit a file on one
    LM> branch and say "I also want that delta over there which is on
    LM> a different branch".

Indeed, very cool, IIUC.  Another thing that sucks in CVS, but which
we need surprisingly often, is the ability to include a file in
multiple projects.  Example, in the Python project we've got a file
called Lib/smtplib.py which Guido will edit and change as bug reports
come into via the Python channel.  Mailman usually just wants to use
the latest smtplib.py file, but it lives under the Mailman project in
Mailman/pythonlib/smtplib.py.  When I see changes happen to the Python
tree, I usually checkout the latest version, and commit it to the
Mailman tree.  This sucks because I've now lost the revision history
to the file under Mailman.   I can kludge around this by evil tricks
like symlinking or <shudder> hardlinking the ,v file in the
repository.  That sucks for any number of reasons (rsync to the
anonCVS, what if I want to do this for lots of files all over the
place, etc.)

Does BK provide any kind of support for this?

    LM> We're weak here in some regards.  We don't support partial
    LM> repositories.  In other words, when you do a resync, you get
    LM> the whole tree.  To deal with this, you will naturally split
    LM> your project up into chunks.  Each of these chunks is a
    LM> repository.  So far so good, but the one bummer is when you
    LM> want to share data between two repositories.  We currently
    LM> don't have any way for data to be in two different "chunks"
    LM> (we call 'em projects) at the same time.

Ah, so I think my answer to above is "no".  Well, I guess I'm no worse
off :)

    LM> and that will DESTROY those two changesets.  You'd better have
    LM> a copy of them somewhere if you want 'em back).

Hmm, it might be nice if some day those were re-doable.

    LM> One thing you forgot to ask about is file renames.

Equally important is directory renames.  Can't be done in CVS, so what
you end up doing is creating the new directory, moving all the ,v
files in the repository, then doing an update -d -P.  The old dir
doesn't go away, it's just pruned out 'cause it's empty.  There's
gotta be a better way.

Thanks for all the info Larry,
-Barry