[Mailman-Developers] Re: [Mailman-checkins] mailman3 README.txt, NONE, 3.0

Harald Meland harald.meland at usit.uio.no
Mon Sep 8 18:16:34 EDT 2003

[Barry Warsaw]

> On Sun, 2003-09-07 at 17:30, Harald Meland wrote:
>> If there is enough demand for tree reorganization to require using a
>> completely new CVS module, has any thought been given to switching to
>> a revision control system that actually *supports* renames?
> Thought about it, but as long as we're on SF and SF uses CVS, it's too
> much work to switch.

I'm not sure which aspect(s) of "SF uses CVS" you're referring to:

 1) SF hosts the "official" CVS repository.
 2) SF has a system for granting project developers commit access to
    the central repository.
 3) SF hosts an anonymous access version of the repository.
 4) SF has routines for gathering "project activity metrics" that are
    (partly) based on CVS access.
 5) Users familiar with SF more or less expect all projects hosted
    there to use CVS.

... or something else?

A complete switch to e.g. GNU Arch
(http://www.gnu.org/directory/GNU/arch.html) does not conflict with
all of these:

 1) SF provides both sftp and http access.  Arch can do archive
    (Arch's name for "repository") access (r/w) over sftp, and
    read-only access over http.
 2) It is possible to use the same file groups SF uses for CVS access
    to do Arch commit access (over e.g. sftp).  However, with Arch's
    support for distributed archives, it might not be necessary.
 3) With Arch, one could either use the devel archive directly
    (because the same archive could be accessed through both sftp and
    http), or one could leverage Arch's support for mirroring of
 4) No good solution here -- but then again, I'm not convinced it
    really is necessary to "solve" this.  I don't think SF's
    popularity-meter is particularly important to Mailman...
 5) Well, I think users with such expectations are bound to be wrong
    sooner or later. :-)

Additionally, a "complete switch" might not be necessary; some
projects are using both CVS and Arch simultaneously.  These setups
typically leave it to the Arch users to do the gatewaying to/from CVS
-- but the CVS users are more likely to get into trouble when
files/directories are moved around, as such changes will be seen as
delete+add operations in CVS.

Finally, there are other systems than Arch our there.  In particular,
Meta-CVS (http://users.footprints.net/~kaz/mcvs.html) provides an easy
(if not backwards compatible) solution to items 1-4 (but still
requires users to change their expectations).

More information about the Mailman-Developers mailing list