• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• In reply to: Jonathan S. Shapiro

This is a multi-part message in MIME format.

------=_NextPart_000_0101_01BFA24A.EA08FB40 Content-Type: text/plain;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Mike Linksvayer asked me (ever so politely) why I have taken leave of my = senses to do yet another configuration management system. Here are some = alteratives I have considered, the requirements I see an immediate need = for (and some that I *don't*), and my sense of how long I expect all = this to take.

CURRENT ALTERNATIVES

The current CM systems out there in the open source world are basically = CVS, PRCS, BitKeeper, and AEGIS (in order of realistic usability).

CVS: I've been using this since 1991, and I'm not happy with it. It = doesn't really do configurations at all, and it lacks a notion of a = local repository, which is vital for people who work over slow links or = portables. I could live with all of this if it got directories and = rename right, but it doesn't. If it were for some reason necessary for = me to recover the version of EROS as it existed in 1992 I don't think I = could do it, and if a CM system doesn't give you that, it doesn't give = you anything at all.

PRCS: no remoting, no rename handling, not complete soon enough. I think = that Josh McDonald is doing a whole bunch of interesting things with = PRCS, and I suspect that the stuff *I* am doing is largely = complementary. He has focused primarily on back-end and comm issues, = while I'm taking the view that disk is cheap and I need configurations. = I very much hope that these efforts will merge, at least spiritually, = and possibly (if Josh proves interested) perhaps even for real.

BitKeeper: Larry McVoy is a smart guy, but the "you can use it as long = as you send me all the deltas" model doesn't wash. There are things we = don't release, sometimes for good reason. Also, it's been in Beta = forever, with no sign of emergence.

AEGIS: Seems to be total overkill. Aegis wants to take over your entire = lifecycle model, and I don't want that. I spent years building CASE = tools, and there simply doesn't exist a single, universally applicable = lifecycle management model. For starters, I just want configuration = management, but see below.

In short, nothing out there is currently doing the job.

NON-ISSUES

I think that Josh McDonald has done some really beautiful work on delta = compression and storage, and that his network transfer stuff promises to = be just as good. I'm eager to use the network transfer stuff. Frankly, = anything that just avoids *redundant* transfers is a damn sight better = than CVS; cleverness can come later. Also, I think that focusing on = delta compression is deferable. Disk space today is $1 per 100 = megabytes. I think delta compression is probably useful, but I also = think that it adds a *lot* of complexity to the storage manager and it = can wait till version 2. Get the function right and then optimize the = storage manager.

WHY:

In addition to simply getting configurations right (obvious), there are = some other issues:

Open source imposes some requirements for access. Security certification = imposes some requirements for access *control*. These two issues cannot = be managed by *any* current CM system, and this is my main motivator. We = need a means to have branches that are tightly controlled by the core = developers, and simultaneously a means for any Tom, Jane, or Harry to = make changes in a local version for later submission into the pot. = Further, we need a means for corporations to build *private* branches = that are not externally visible until a release occurs (if ever). = Finally, we need a system that can let two companies set up a shared = workspace with some reasonable story for security.

In the limit, we need something programmable, because we do need = lifecycle integration but there isn't a single right answer.

So that's what I'm trying to build here, in stages.

Your thoughts, as always, are appreciated.

------=_NextPart_000_0101_01BFA24A.EA08FB40 Content-Type: text/html;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

[ Next ]
• In reply to: Jonathan S. Shapiro