Fog Creek Software
Discussion Board




CVS: Joel not taking his own advice

I'd be very curious to hear why Joel uses CVS.  It's pretty clear that Perforce is better and Bit Keeper even better still.  Fog Creek being small probably doesn't need the features of Bit Keeper but they probably do need the features of Perforce (atomic checkins)

Joel's opinion is "a good company uses the best tools money can buy".  Does this mean Fog Creek is not a good company?  Does it mean CVS is the best tool?  (even the CVS team knows that is not the case as you can read their excuses and prayers that somebody will add the missing features)

What's up with that Joel?

Gregg Tavares
Monday, February 03, 2003

cvs is totally, completely good enough for our needs. When it stops being good enough, we'll consider something else.

Joel Spolsky
Monday, February 03, 2003

On a similar note, is there a real difference between "good enough" and "best"?

Serously: if it will solve your problems completely, then it's the best. It doesn't matter if something else does more, you don't need it: it's not solving any problems you have.

Just a thought (Also, CVS is free. If it works, use it. Why buy better when "good enough" is available?).

On a similar note, this reminds me of an important paper: "Worse is Better". Perfection is not useful because it is not attainable. "best" is not useful, because it is massively overkill, and often much more expensive than "good enough".

Mike Swieton
Tuesday, February 04, 2003

My thinking is along the same line as Mike's. In my mind, "best tools money can buy" still has a cost/benefit factor in the decision as to what is ‘best’.

Is it worth paying 10x as much for a tool that does 2x? It might be, if you need the extra functionality. If you don’t need the functionality, the money’s wasted.

Another factor is the upgrade path. If it’s easy to upgrade to a better/more expensive product when you eventually need the features, I’d use the cheap one that meets my immediate needs (I have other things to do with that money right now). OTOH, if the upgrade path was difficult, and I knew I’d need the advanced features eventually, I’d be more inclined to pay the price for the more advanced one right now.

jeff
Tuesday, February 04, 2003


Actually, the initial post sounds less like a "You may not be using the best tool" message than a "I need to justify my recent expenditures" message.

Only a fool changes things that are working without good reason. Upgrading to the latest shiny new toy is not a good enough reason on it's own.

Bruce Rennie
Tuesday, February 04, 2003

"cvs is totally, completely good enough for our needs. When it stops being good enough, we'll consider something else."

I sincerely doubt it.  By "good enough" I assume you mean "does everything that we need it to do to reasonably optimize our productivity as it relates to source control" rather than "we are profitable now and are not interested in being more profitable."  I think you are simply not aware of the practices that more advanced tools allow and the productivity gains that can be made by using them.

For one simple example, you recently talked about doing a "binary search" to look for a performance bug.  You didn't say how you selected your check-outs, nor how you ensured that they represented self-consistent code states, i.e., you didn't cross the boundary of a checkin.  You probably glossed over that "detail" because in CVS you *can't* do that with any level of certainty.

If you had a changeset oriented tool, you could have done this search not only with confidence that each build was self-consistent, but you could have narrowed it down to the specific check-in that caused the changes, not just the day.

And that is the tip of the iceberg...

Robert
Tuesday, February 04, 2003

"On a similar note, is there a real difference between "good enough" and "best"?

Serously: if it will solve your problems completely, then it's the best. It doesn't matter if something else does more, you don't need it: it's not solving any problems you have."

Would you acknowledge that many shops have problems that they don't think of as problems, or they think those problems are unavoidable, when in fact they are not?

Because Joel, or anyone else, thinks "CVS is good enough" does no make it *necessarily* so.

Education about the practices surrounding source control is, in my opinion, some of the lowest hanging fruit in software development productivity right now.

Robert
Tuesday, February 04, 2003

Regarding the "isn't good enough best" thread: The problem with this argument is that it is often used as a rationale to justify mediocrity.

It depends on which side of the question you're on -- producer or consumer -- and how well each side knows what it is actually trying to accomplish.

Jeff Kotula
Tuesday, February 04, 2003

Perforce is clearly much better than CVS.  Its ability to maintain and track through branched code, labelling is painless and can be done by any user - not just administrators, checkins are atomic.  Perforce doesn't leave its baggage hanging around in the form of CVS directories all over the place (that is so stinking sloppy, it isn't funny).  Perforce is powerful and intuitive.  It allows average users to harness the power without becoming a master of it (unlike so many other so-called "technologies", which are poorly thought out and at the end of 2 years get thrown away for their uselessness).

But changing version control systems takes SO much time and effort that it perpetually gets put off.  That's because the marginal gain in productivity does not match the cost - tool cost (low) versus days lost and mistakes made (high).

Anyhoo...

Nat Ersoz
Tuesday, February 04, 2003

"You probably glossed over that "detail" because in CVS you *can't* do that with any level of certainty"

Actually, with CVS it is perfectly possible to do what he needed to do. (Not only that, but you can check out a particular version of the software with absolute certainty that you are using the same files as were used the last time that version was built.)

The first step would be to tag the entire code base at the time the daily build is done. (A two line script can issue a command that says 'tag all files with the name 'DAILY_BUILD_<date>'' and then check out a copy of those files to the local hard drive for compiling. The daily build system should include a script to manage the source code - the actual developer shouldn't need to think about it, or remember that it needs to be done.)

You can then easily use one single command to get a copy of the source code (including makefiles, build scripts, etc) from any particular date.

This means that it is trivial to get an exact copy of the source code as built at a particular point in time. Given the size of the Fog Creek development team, knowing the day on which a bug was introduced should be more than sufficient to quickly look at what was done that day and fix it. Getting and compiling the code would be easy - testing it to determine if the bug was present in that build would be the slow and difficult process.

Btw, if you have three people all working in one room, then collisions during committing and checking out files are trivial to avoid. If you have three hundred people scattered around a building with an office for every person, then it's probably worth using a system that does more to prevent collisions. Given the size of Fog Creek Software, CVS may well meet their needs perfectly, even though there are other systems that do things that CVS doesn't.

andrew m
Tuesday, February 04, 2003

"Actually, with CVS it is perfectly possible to do what he needed to do. (Not only that, but you can check out a particular version of the software with absolute certainty that you are using the same files as were used the last time that version was built.)"

That depends on what you mean by "needed to do."  What he did is check out by date - at least that's what he said he did.  Which provides no guarantee that he didn't cross a check-in boundary.

Tagging makes it possible to make any given revision frontier reproducible, but find me a shop that tags every self-consistent revision frontier, and I'll eat my hat.  It's extra work and a maintenance nightmare to boot.

Robert
Tuesday, February 04, 2003

"good enough for our needs" is not the same as "the best money can buy".

A Pentium II 266 with 128 Mb of Ram and a  15" CRT is "good enough for our needs" at RatScrapeDevelopers.com, but it is never "the best money can buy"
50 devs on a shared 10Mbit network with a single dial out ISDN line to the Internet is "good enough for our needs" at PennyWisePoundFoolish, but never "the best money can buy"
An EBay $5 copy of Borland JBuilder Pro 4 is "good enough for our needs", but never ...

you get the picture.

Just me (Sir to you)
Wednesday, February 05, 2003

*  Recent Topics

*  Fog Creek Home