> 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.
>
> And you are suggesting that this is OK? Fine, go to the head of the
> line of people I want nowhere near my data.
No, I'm not. I'm not suggesting that no compensation for the fact that
disks and filesystems go bad is needed. What I'm saying is that that
compensation should not need to be application-level. If I need to do
a lot of checksumming and manual parity calculation and such in my
application, then either the OS author or whoever put together my
machine seriously fucked up somewhere. If my data gets silently
corrupted without me noticing for months or years, then there are
problems that no SCM can solve.
Also, I'm not claiming that having an SCM do extra stuff like
corruption checking is bad. It's pretty cool, actually. But you made
it sound like Peter should be run out of town and have small children
publically mock him for not building it into his system. That's not
just wrong, it's rude.
> And another thing: while you and your buddies may not think that this
> is a problem to worry about, you aren't exactly representative. If
> people put money and/or effort into using a source management system,
> don't they have the right to know that the vendor did something to make
> sure that things wouldn't break?
"you and your buddies"? "you aren't exactly representative"?
Larry, could you do me a favor? Could you be a little more
condescending? I almost got the impression for a second there that you
might possibly have the tiniest smidgeon of respect for someone who
might dare to disagree with you.
We have over five years worth of research code in our repository. I
think that's more than a little effort, and we're definitely worried
about protecting it. That's why we make sure it's regularly backed up
and we often burn snapshots to CDROM. We may be a little insignificant
research group and not big important Captains Of Industry, but we do
care about our code. Our sponsors, who _are_ Captains Of Industry,
also care about our code and us not losing it, so that's a little
extra motivation right there.
Also, if I buy BitKeeper, store lots of important code in it, and it
fucks up my repository, what can I do? I mean, I can whine about it a
lot in public, which might make me feel better, but can I do anything
that gets me my code back or provides me with actual compensation? Can
I get a refund? Can I sue you? Can I say "He did it! Blame him!" to my
boss or my sponsors? If the system breaks, then fundamentally I really
don't care whose fault it is, I just want my data back.
> You'd have a point if RCS told you when there is a problem, but it doesn't.
RCS shouldn't have to do this. If I need my data uncorrupted, I'd
better use mirrored disks with parity. If I might need data for months
or years, I'd better have offsite backups and burn important bits onto
CD in case a tape dies.
It's nice if my application helps me out there, but if I'm depending
on it doing so, then I deserve to lose my data when it fails. I'm sure
BK's integrity system is nice, but I think I'd prefer to have more
than a single piece of software to fall back on.
> You'd also have a point if this didn't happen in practice, but it does.
> So you have no point. He's wrong. If you disagree, you can use a stupid
> application to store your data but don't pretend that you speak for the
> majority.
Can you explain to me where you got this "Nat uses raw RCS with no
other safeguards" strawman from? I'd really love to know.
In practice, stuff breaks and overheats and catches fire and get
stolen and deleted and lost and water damaged and what have you. Will
BitKeeper protect me from that too? If so, cool, sign me up. If not,
pardon me for wanting to have safeguards other than some piece of
software.
> Great. I'm equally uncomfortable with you not paying for it in that case.
I'm glad to know our research isn't pure enough for you, Larry. Will
you admit that maybe all the people who complain that when you call
BitKeeper "open" you don't actually mean "open" have a point now, please?
> Feel free. I have no interest in getting you to use something you don't
> need. In fact, when people say "why should I use BK instead of XYZ" I
> respond with "Is XYZ working for you? If so, you shouldn't". You'd be
> amazed to know that 95% of the people say "No, it isn't working". But if
> Perforce or CVS is working for you, why are you in this conversation?
> If you're happy, you're happy. If not, and BK costs you less than the
> problems cost you, that's a win.
Funny, a few messages ago you seemed to be saying something totally
different -- it was more like "Why would you be stupid enough to use
Aegis when you could use BitKeeper instead, which will solve all your
problems and make toast for you in the morning?".
Part of the point here is that those of us outside of BitMover and the
beta groups really have no idea whether BK will solve ANY of the
problems that CVS, Perforce, ClearCase, Aegis, or whatever don't. You
say they will, but you haven't produced anything to back it up with.
You attack Peter for having the temerity to think that he's produced a
good system by waving your ridiculously expensive vaporware around,
and then when someone mentions a much cheaper product that a lot of
people are pretty happy with from an actual commercial company with
support, you get huffy. I'm just trying to point out that BitKeeper is
not the only game in town, no matter how much you love it. Yelling at
people will never convince them that BitKeeper is good. Only BitKeeper
itself can do that. Yelling will only make them think you're arrogant
and obnoxious, and wonder what kind of support you'll provide. That's
no help.
> > If I use BitKeeper, what assurance do I have that BitMover will stand
> > behind it for 20 years? I don't want to be a doomsayer, but we've all
> > heard the statistics on how many startups make it. If the unfortunate
> > happens and BitMover tanks, what happens to me and my BitKeeper
> > license? Am I screwed?
>
> Nope. As I have publicly stated before: if the openlogging.org domain
> BK servers go away and stay away for an extended period (3-6 months),
> and the company refuses (or is unable because they are gone) to maintain
> them, then the software becomes GPLed.
Right, so I'm at exactly the same place I would be if I used
Aegis. Since something Linux shows us that users can keep free
software alive and make it great, I'm not screwed. I'm okay. Except,
wait, no, I'm not. I'm also out an eighth of a million dollars.
Fuck, I guess I _am_ screwed.
> Hey, Nat, my man. Go back to the start of the thread and notice I didn't
> start this, it wasn't my marketing, it was that Aegis guy who got the
> ball rolling.
But you jumped into it and harangued him about it. "He started it" is
not and never has been a good excuse for this sort of thing, Larry.
Uh, I mean, "Larry, my man".
(hint: take the marketing hat off. talk about the technical
details. give us reasons other than "because I say so". accept that
others can be more than just mouth-breathing annoyances. we'll like
you for it. really. we might even buy your software.)
(especially if you consider adding an educational discount. education
is the future, y'know.)
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead- 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/