> On Mon, Sep 27, 1999 at 10:04:55PM -0400, Nat Lanza wrote:
>
> [noise about not seeing BK yet]
>
> [earnest comments about Larry's good will to all mankind]
>
> > Larry McVoy <lm@bitmover.com> writes:
> > > It is a _fact_ that disks go bad and that file systems can corrupt
> > > files. It is a _fact_ that billons of dollars of IP are put into
> > > source control systems. And you think it is OK to just say "fix
> > > the OS"? Bully for you but hell would freeze over before I'd let
> > > you near my source.
> >
> > There's this invention you might be interested in. It's called
> > a "tape drive".
>
> In RCS files, the way the file format is layed out, you'll never know
> that a revision is bad unless you ask for it and discover that it is
> bad. In other words, you can have the middle of a file (like one
> block or sector) go bad, and you may not find out until a long time
> later. When RCS processes the files, it does nothing to verify that
> the old data is valid. So months, years, can go by before you need that
> old release to support an important customer. And then those lovely
> tapes which you made (you did make them, right?) may well be bad.
I have mixed feelings about the features of every revision control system I have
seen, but here is a point I can fully concur with. This problem has bitten me with
both SCCS and RCS. Something nasty gets into the tree, and nobody notices. A year
later, when the problem is spotted (probably because the screwed up version is
needed for support purposes) its damned hard to figure out what went wrong. Its
also pretty messy cleaning up the trail of change upon change that will have
followed the original unfortunate incident. I consider this one of the significant
risk factors in using any revision control system.
By the way, aren't most tape backups WOMs?
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/