Slashdot Mirror

I find it interesting that in their Assessment of Various SCM Systems there is no mention of BitKeeper, Arch, or Subversion, all of which have been brought up here in the past.

Does anyone know how they compare? It seems to me as though this space is becoming increasingly crowded. Choice is a good thing, I just fear that it might be at the cost of being able to easily communicate code between developers.

In opening, what is wrong with CVS? If it's such a big piece of shit, where are CVS' authors to address the problem?

With arch, subversion, Bitkeeper, Perforce, and Starteam there is a large group of choices for someone setting up a new project. Having the choice is a good thing, but there is a lack of good information on the topic.

I'm looking to get a RCS setup soon for an open source project, and this article reminded me that maybe CVS isn't a given. To decide, I can go read the docs for each, set each one of them up, and find the one that best suits me. Man, that's gonna suck.

Someone needs to sit down with each of these (and any others of significance) and really do a comparison. Investing the time to get your brain wrapped around a new RCS is very expensive.

Sorry about the headline, I couldn't think of a short-enough one that'd fit.

BitMover also has a clause to help free software developers in the event of the company going out of business, located here (Correct me if I am wrong).

It says, '5. CONVERSION TO THE GPL
The BitKeeper Software will be made available under the terms of the GPL in the event that all Open Logging servers cease to function for a continuous period of 180 days starting on or after June 1st 2000.'

This looks to be applicable to the free-as-in-beer version only, as far as I can tell, but still, it's not exactly a big problem.

http://bitkeeper.com/Products.Comparisons.Perforce .html

Allthough this is marketing poop so it should be taken with a fine grain of salt, it might answer your question.

Now I'm confused!

I've been using CVS for years and read with great interest the recent Linux Journal article about the Subversion project to created a CVS replacement that is better than CVS.

Then I see a Slashdot story about arch.

Now, my FearLessLeader starts using Bitkeeper.

Should I move from CVS and, if so, which is best?

Subversion was deliberately designed to address CVS's shortcomings, not to break new ground. Our philosophy was essentially conservative: CVS basically works, but has some bugs and maintainability problems. Let's keep the model and fix the problems. Result: Subversion.

The ideal situation is a world where both models have good, free implementations. Then we'll all very quickly find out which model works better. :-)

-Karl

The solution to the problem is really quite simple. As Larry McVoy, who maintains the powerful but non-free BitKeeper RCS system and knows a thing or two about patches, has hinted towards kernel.org may be better off not providing a tarball for each release, instead providing some kind of utility that downloads the latest available full kernel, but only if necessary, plus patches. I'd be all for it. In the meantime, there are a number of incremental patching systems for the Linux kernel that automatically download patches, verify their signatures and patch the kernel which may be worth looking into to save time, bandwidth and resources:

• dlkern
• buildkernel
• lkpatch, which has fallen into disrepair
  

Of course, it goes without saying that everyone should still use their local mirror, particularly as kernel.org will only be accessible to mirrors for the forseeable future.

I've never used SourceSafe.

You didn't mention how many active developers are working on your project.

Where I work, we ran into trouble with CVS when we had 40+ active developers working in the same repository. If you have many different teams whose changes overlap on (even a few) common files, it can be difficult. In theory, branching helps with this, but in practice, branching just moved the conflict-resolution to a different step of the release process.

Hmmm... I guess a lot of our trouble was from how we organized our source tree and assigned projects. (Blame the managers! :)

For a while we had switched over to BitKeeper. It has it's limits, and we where definitely pushing them :) but it's a well thought out product. It did help manage the risks associated with code conflicts.

Try here.

I recently had the job of evaluating what SCM system to use for our company. We were using CVS at the time.

I believe that the complaints your bosses have about logging and concurrent editing can all be fairly easily fixed in CVS.

The major gripes we had with CVS were:
. slow (see below)
. merging between branches was miserable, because the system didn't keep track of what had already been merged
. renaming files lost all the history
. windows interface was cumbersome

We actually worked with a system layered on top of CVS that allowed us to submit batches of files at once, in a single transaction. This was the major cause of slowness, and CVS didn't really support transactions, so in some sense we were just fooling ourselves. The other major cause was doing a 'cvs update' on a large tree could be slow.

Most of the problems we had could've been fixed
if we spent the time to fix it. Some (transactions, renaming) we couldn't really fix at all. But, when I looked at everything I wanted to fix in CVS, I found that I had just described Perforce's feature set, and when I looked at how they implemented things, they did it like I would've. Plus, comparing the cost of Perforce (relatively cheap) to the time it would've taken us to implement the same features ...

So, we switched to Perforce, and I've been (more or less) happy since. The branching structure is a little weird (compared to ClearCase's, which is the most intuitive I've seen), but we're learning to live with it.

At a previous company, we used ClearCase. This was also a fine product, and it does a few things that no other product does, but it's very expensive, and a major hassle to administer.
ClearCase (at least in the mode we used) implements its own filesystem, and can provide a level of security that the others just can't. But, is this worth paying 10+ times the amount for it?

I also looked at AccuRev. This was about on a par with Perforce, and had one or two features that looked really cool. But, in the end, Perforce won mostly because we went with the product that had bigger market share and more people had used it before.

VSS wasn't an option because we're a mostly linux based shop, and because I had heard many of the complaints that others are making as well.

PVCS I think is mostly an also-ran in this day and age. I think most new source-system users use one of the other previously mentioned systems.

One new open source project (Subversion) looked promising, but it was too immature for us to use.

Bitkeeper also looked interesting, but not enough so to beat out Perforce or AccuRev.

Another thing you might want to consider is how well the SCM integrates with a change mgmt system (or bug/task database). Perforce has a simplistic change database built in, but it's good enough for what we want it to do, and it can also be used with Bugzilla and a few other systems. Of course, CVS and at least ClearCase can do these as well. I've found Bugzilla somewhat cumbersome to use on limited inspection. Other freeware systems (GNATS, for example) are very weak.

CVS lacks a few features that make it really uncomfortable to work with.
-atomic checkins on multiple files: basically meaning that you can't really tell what files came in with each checkin, so backing out of a change is a chore, also it's possible to checkin
only a part of what wanted to (if the network goes down) resulting in a broken tree
-file renaming breaks file history
-no directory renaming
-no disconnected operations on the repository(e.g. checking the file history when you are on a laptop in a plane)
-branching and multiple merges back into the trunk is a little awkward
-setting up a staging area for integration of changes is similarly awkward

The alternatives:
Bitkeeper looks really nice, I've only played with it though, not used it in any serious development. It follows a model that every developer gets his own repository, and then push changes around these repositories. The license allows access to the source code, but is not quite open.

A lot of people like Perforce. I don't have much experience with it myself though.

Visual SourceSafe is slow over the network, seems to corrupt files easily, and not so friendly cross platform. It has a nice GUI, if you are into that kind of stuff. Has similar problems with CVS regarding branching and atomic transactions.

ClearCase is really expensive(in computing resources, money, and adminstration costs). On the other hand it has nice integration with rational's workflow and bug tracking products.

The licensing is a bit wacky, as it's not exactly free.

As an individual, I could use some SE methods to develop an Open Source app, but who does that? No one I know of. I actually think that it might work and produce some good quality stuff if they did. Especially if all the people working on it have access to the same tools.

One important issue is the tools. KDevelop may be nice, but how does it help you do software engineering? It doesn't. What we need is quality CASE tools. ArgoUML shows promise but is lacking a lot of features and is still early on in its development. Together/J is pretty nice, but you need the commercial version to get all the features.

I have never seen an open source app that deals with requirements and design documentation. The thing we like to be able to do in industry is trace (follow) requirements to their implementation in design and code.

And then there's version control. CVS doesn't have all the features of something like ClearCase, but bitkeeper is looking good.

Why does so much commercial software suck when compared to open source? Probably lots of reasons. Market timing pressures, poorly documented legacy code, bad management. But maybe the most important one is lack of large scale peer review. In open source there are a lot of fresh faces who are free to come in and say:

"This design sucks!! We should scrap it and start over and we will come up with something better. Fine, i'll do it myself in a few hours."

...with some justification, IMHO, Linus
decided that CVS could not handle the
Linux kernel (it's just too many files).
And it is true that on a large
project with lots of history, certain
CVS operations can become
might slow. I'd love to see it in CVS too,
but I can't deny that Linus' complaints
are valid.

If I remember correctly,
the Linux kernel is (or soon will be) in
BitKeeper,
which was specifically designed with
the Linux kernel in mind, although it
is supposed to be of general utility too.
Unfortunately, BitKeeper's license is not
completely free, which I think prevents its
wider adoption. I have no idea of its
technical merits, never having used it myself,
but from what I've read at their web site
they appear to be thinking carefully
about how to do revision control.

First off, the product isn't licensed as free software or OSI Certified -- because there's not yet either product or a license (which is to say, WRT product, there's a program, but it's not yet product).

From what I've pieced together of comments of Larry's (SVLUG), web blurbs (his, others), and the license sketch currently on the download site, terms will be liberal but not quite free. Larry likes the idea of free software, but isn't convinced he can make a commercial go of it all in and of itself. Specifically, my impression was that the source is available and hackable (a specific requirement of Alan Cox, per Larry).

Given that his business model right now is sort of half-software house, half-consulting services (SW: BitKeeper and others, services, Hunkin' Big Clusters), I'd like to hope he eventually discovers he doesn't have to worry quite so much about this. Along the lines of Cygnus.

For insight on licensing, you might want to read:

• The current COPYING file of the BitKeeper FTP archive.
• A bit about BitKeeper and Free Software, at the BitKeeper site.
• An LWN feature on BitKeeper and its licensing|business model.

Note that the most commonly cited alternatives to Larry's solution all have pretty heavy consequences:

• Sun Community Source License. As the wags say, it's the (Sun Community) + (Source License), not the (Sun) + (Community Source License). Sun gets some hefty rights reserved to itself, largely so that it can continue to control the direction software to benefit itself.
• The Alladin Ghostscript licensing method -- what's been called "Delayed Public License" -- software is licensed under the GPL (largely because Peter Deutsch promised RMS that he always would) -- but only after an initial period in which the software is covered by a proprietary license. This means that the OSS version of the software is always slightly behind the proprietary version.
• Shareware|Freeware -- there's lots of software out there that's cost-free to use, but the source isn't available. Convenient, yes. Full benefits of free software, no.

The BitKeeper license is most like the SCSL, though the intent seems to be to build a code escrow term into it which reverts to GPL should BitKeeper fold or fail to maintain the source.

Addressing specific points of your post, certain libs of BitKeeper will be GPLd or LGPLd, allowing them to be redistributed or incorporated into projects under terms of the GNU [L]GPL.

WRT your bugfix and feature comments -- the BitKeeper license is oriented around limiting potential for fragmentation. It's got some elements of the common view of the xBSD development model (centrally controlled cabal), and I'll share your view that this is, if not a Bad Thing, at least a Thing of Questionable Worth (TM).

I can't see how your last point (source is still closed) stands with your other arguments. The source is available, it can be reviewd, modified, and mucked with, It's not compliante with the OSD, but it's certainly not proprietary either.

Larry's blazing a new path here, it'll be interesting to see how it plays out.

First off, the product isn't licensed as free software or OSI Certified -- because there's not yet either product or a license (which is to say, WRT product, there's a program, but it's not yet product).

From what I've pieced together of comments of Larry's (SVLUG), web blurbs (his, others), and the license sketch currently on the download site, terms will be liberal but not quite free. Larry likes the idea of free software, but isn't convinced he can make a commercial go of it all in and of itself. Specifically, my impression was that the source is available and hackable (a specific requirement of Alan Cox, per Larry).

Given that his business model right now is sort of half-software house, half-consulting services (SW: BitKeeper and others, services, Hunkin' Big Clusters), I'd like to hope he eventually discovers he doesn't have to worry quite so much about this. Along the lines of Cygnus.

For insight on licensing, you might want to read:

• The current COPYING file of the BitKeeper FTP archive.
• A bit about BitKeeper and Free Software, at the BitKeeper site.
• An LWN feature on BitKeeper and its licensing|business model.

Note that the most commonly cited alternatives to Larry's solution all have pretty heavy consequences:

• Sun Community Source License. As the wags say, it's the (Sun Community) + (Source License), not the (Sun) + (Community Source License). Sun gets some hefty rights reserved to itself, largely so that it can continue to control the direction software to benefit itself.
• The Alladin Ghostscript licensing method -- what's been called "Delayed Public License" -- software is licensed under the GPL (largely because Peter Deutsch promised RMS that he always would) -- but only after an initial period in which the software is covered by a proprietary license. This means that the OSS version of the software is always slightly behind the proprietary version.
• Shareware|Freeware -- there's lots of software out there that's cost-free to use, but the source isn't available. Convenient, yes. Full benefits of free software, no.

The BitKeeper license is most like the SCSL, though the intent seems to be to build a code escrow term into it which reverts to GPL should BitKeeper fold or fail to maintain the source.

Addressing specific points of your post, certain libs of BitKeeper will be GPLd or LGPLd, allowing them to be redistributed or incorporated into projects under terms of the GNU [L]GPL.

WRT your bugfix and feature comments -- the BitKeeper license is oriented around limiting potential for fragmentation. It's got some elements of the common view of the xBSD development model (centrally controlled cabal), and I'll share your view that this is, if not a Bad Thing, at least a Thing of Questionable Worth (TM).

I can't see how your last point (source is still closed) stands with your other arguments. The source is available, it can be reviewd, modified, and mucked with, It's not compliante with the OSD, but it's certainly not proprietary either.

Larry's blazing a new path here, it'll be interesting to see how it plays out.

Is the new development kernel going to use BitKeeper or some other similar source management system?

I've been wondering on this for a long time now , I heard Linus at least some of the other kernel developers were interested, what's the current status of such a move?

Is the new development kernel going to use BitKeeper or some other similar source management system?

I've been wondering on this for a long time now , I heard Linus at least some of the other kernel developers were interested, what's the current status of such a move?