Fw: TeamOne Jonathan S. Shapiro (shap@eros-os.org)
Mon, 10 Apr 2000 12:30:53 -0400

I think John intended this to go to the list...



From: "John C. Randolph" <jcr@idiom.com> To: "Jonathan S. Shapiro" <shap@eros-os.org> Sent: Sunday, April 09, 2000 6:53 PM
Subject: Re: TeamOne

>
>
> > "Jonathan S. Shapiro" wrote:
> >
> > John and I have talked about TeamOne before. In short, I think that a
> > filesystem-based mechanism is not the best way to go. Here are the
> > reasons:
> >
> > 1. Filesystem interfaces are not the least bit standard. Each platform
> > essentially requires a complete new implementation of the FS. Often,
> > *minor* versions of a platform require FS rework.
> >
> > 2. The filesystem is unable to know what constitutes a "consistent
> > cut" of the space. It can watch the writes and track everything at
> > each close, but it has no way to know which "snapshots" are actually
> > worth saving and which are junk.
>
> In teamnet, that was up to the users. Everytime they said "remember
> this", the open checkpoint got closed, and a new open checkpoint created.
>
> > 3. The two main advantages of filesystem approaches come in handling
> > of "rename" and supposedly "undo". The first is real; it is
> > unfortunate to have to do "rename" using some particular tool, but
> > this doesn't seem (to me) likely to be fatal. The second is deceptive,
> > again because the filesystem doesn't know which snapshots are good
> > ones. The upshot is that you need to say "save the current state" in
> > order to give it a name so that you can sensibly roll back to it. If
> > you're prepared to do that then a filesystem isn't necessary to solve
> > the problem.
> >
> >
> > The bottom line on this approach, however, is that I don't have time
> > to build and maintain a new file system. My objections to CVS lie not
> > in it's implementation as a command-line tool, but in it's inability
> > to track configurations (at all). Secondarily, it would be nice to
> > have a spiffy visual interface, but I really do mean that
> > "secondarily."
>
> Have you looked at the various SCID implementations that the
> smalltalkers are doing?
> I'd like to not only have a secure, distributed CM system, I'd also like
> to quit keeping my OO source code in flat files!
>
> To put it in SQL terms, I'd like to just pipe the results of SELECT
> STORAGE_SPEC, METHODS, FUNCTIONS FROM CODE_TABLE WHERE CLASS = MYCLASS
> AND VERSION = CURRENT_VERSION into the appropriate compiler.
>
> -jcr
>
>