Slashdot Mirror

I'm starting to look into using Cons for a cross-platform C/C++ makefile alternative. [...]

Any idea how it compares to Jam?

(If you don't, then I'll have to see for myself.. *lazy* :)

While I'm not officially responsible for the build process at my workplace, I've taken that responsibility as we've been porting our code to a new operating system. Here are some things we've learned that may help you.

We recently switched from Make as our build tool to Jam which has worked great. Like you, we didn't have the option of using GCC on every platform, and Jam made it easy to configure all the operating systems we're interested in using with the fewest headaches. After using Jam for quite a while now, I think all of the developers and I are very happy with the decision to axe Make. Honestly, I can sympathize with your effort to use Make to do all your compiling since we gave it some effort before switching to Jam. Try Jam - you'll be amazed at how much simpler your build process becomes.

Whether or not you use Jam (though we use Jam to do this), setting up nightly builds, capturing the output, and sending status emails with the results makes bug finding much simpler, especially on multiple platforms. Part of the nightly builds include built in testing. If any of the tests fail, we know we've broken something in our code.

Another suggestion... Look for a threading wrapper package like CommonC++ or ZThreads. Both are fairly well developed now and make programming multithreaded applications for multiple platforms pretty easy. For multiplatform GUI tools, try FLTK. It's tiny compared to WxWindows or other bloated GUI wrappers, plus it's easy to use.

.. and they use Perforce. :-) And Perforce offers an Open Source license to any project that develops Open Source. They're also much more reasonable then a certain somebody.

.. and they use Perforce. :-) And Perforce offers an Open Source license to any project that develops Open Source. They're also much more reasonable then a certain somebody.

even working on dual-processor machines and using 'make -j4' to allow multiple jobs, the nature of how makefiles calculate dependencies can make it very difficult to get much work done in parallel. other 'make'-like systems, such as

Jam/MR do a better job of evenly building large, multi-directory projects.

Perforce is a very nice SCM tool for large-scale projects.

They post their price list, have reasonable prices, have a free(beer)limited user version availible, and from my experience conduct themselves professionally.

Why would I want to deal with Larry and BitKeeper?

Perforce is a very nice SCM tool for large-scale projects.

They post their price list, have reasonable prices, have a free(beer)limited user version availible, and from my experience conduct themselves professionally.

Why would I want to deal with Larry and BitKeeper?

But the idea of retroactively adjusting licenses and forcing compliance for _existing_ users seems like it's not quite fair. (Even Microsoft can't force you to install SP3 or upgrade office 97, even thought they'd like to. Even the GPL lets you choose which version of a later license you'd like to be bound under.)

What's going on here is _existing_ users under an old license have to upgrade to new terms.

Bottom line, I'd just rather deal with friendlier people. If better development tools are the order, and non-free software is okay, I'd look elsewhere?

Otherwise, what's the next license change going to look like?

$5,800 for a single license, and then $1,200 / year starting the second year...

I'd like to point out that Perforce licenses cost on a fraction of that. Plus, you can request free licenses if you are a private person and developing open source software. Look here. The company that I work buys commercial licenses for the work that my group does, and I have a free licensed server at home for my work. Everybody wins

Depending on your set of religious tenets, it's either the same thing as BitKeeper, or completely different.

-dB

I agree with most of the article, except they didn't get the Perforce right. See here for more info.

Also, check out jam. It's by the same people that brought you perforce.

The feature of CVS I miss dearly is annotate

Have you tried the p4pr program from Perforce's supplemental tools page? It does pretty much what you want, albeit slowly for our large (several million LOC) repository. It doesn't have support in the p4-emacs integration yet but I'm working on some.

Perforce concentrates on doing one thing well - tracking of software changes. It is not intended to be a work tracking system, which some of the more expensive products provide. It does not provide a GUI (although, why would you ever want to leave emacs anyway?). We use it integrated with our own web-based work management system and did not have to adapt our practices to it. The merge capability is excellent.

It's weakness are tolerable and somewhat unobvious. We felt it important to be able to compare changes in aggregate releases for debugging and reporting purposes. We found no products that do this well. The bookkeeping for this is a little tedious in Perforce and somewhat prone to misreporting old changes from deleted files. The form-based interface can also be a little confusing for things like branching - I see no reason why this could not be simplified.

In looking at configuration management, I think you have to concentrate on some of the basic principals:

like always knowing what you have

like being able to monitor changes in the software

like the tool being an aide to getting work done, not a barrier

like the tool supporting your change process, not imposing it's own

It is very difficult to evaluate some these products (mainly due to pushy sales people). Perforce was easy to evaluate and worked well for us. Putting in Perforce (migrating from CVS) was easy. Don't be fooled by a fancy GUI.

Actually, you can work detached with perforce

It's not nicely integrated or anything, but it's definitely possible

There is also an Emacs client for Perforce. It's not completely full-featured, but it means you don't have to bother with any of the standalone clients when doing basic editing and version control tasks (You are using Emacs as your editor, aren't you?). When I need to do something fancy, you still need to use one of the standalone clients (GUI, commandline, or web).

Besides the Emacs integration, there are integrations for Developer Studio, Windows explorer, Perl, Python, Forte, Eclipse, etc. These are all available at Perforce User Interfaces & Integrations.

I love perforce too. And if you are either an open source developer or you just want to use it for personal use (two users max) you can use if for free. Check out their licensing here (scroll down for open source info) and here

Plus it's so easy to install on a linux server. There's a bit of a learning curve with how the system works but in less than a day you'll be checking in and out and branching without a problem.

I love perforce too. And if you are either an open source developer or you just want to use it for personal use (two users max) you can use if for free. Check out their licensing here (scroll down for open source info) and here

Plus it's so easy to install on a linux server. There's a bit of a learning curve with how the system works but in less than a day you'll be checking in and out and branching without a problem.

Creating a branch is very much like copying all the source to another directory (e.g. you had all your source in mysoft directory, which is your trunk.. when you branch, you copy that to mysoft2 directory and now you have a branch.. best of all, every new branch takes up a miniscule amount of disk space, storing only the files you actually change). And then Perforce supplies you with powerful integration tools to let you synch changes across branches.

It has some flaws, like no version control on client, branch and label specs, so if somebody messes up the definition of a branch, you can't step back to the last version, but otherwise it's an excellent source code management (or whatever the right term is) system.

If anyone's curious about P4, they can read the manual.

Serena They have a variety of ChangeMan products, but I haven't evaluated any yet. The demo looked promising, but I have no idea about cost.

Rational They are expensive, and pretty good. Supports Windows, quite a few unix variants, and SuSe zSeries.

AldonSupports AIX, AS/400, and Windows. The product is a port of their original AS/400 change management software. No idea about cost.

I'll be looking at BitKeeper today, thanks to some other replies here.
Personally, I prefer Perforce. The atomic changelist feature is reason enough, but the product is rock solid and easy to use, and performs well over a broadband VPN link. That being said, the product currently doesnt support the OS/400 native object file system, only IFS (Samba style) files. Perforce informs me that this is an item on their todo list.

Personally I like Perforce; it's simple, flexible, straightforward, and it's pretty aware of what its job is and isn't. There's a gui client for Windows, and a command line for Unix, and it handles multi-megabyte binary files just fine. But it doesn't do binary diffs well, and it's not set up for different media types. I've heard it can be pretty cheap if you talk to Perforce Sales right (floating head? Don't ask me.)

One system that I've heard game developers rave over is alienbrain, which has built in support for a bunch of different media types and basically assumes it's dealing with a bunch of binary files or images from the get go.

At 10K for ten users it's not exactly freeware, but from the reviews it looks like some game designers love it like their G4 powerbook. But that's probably too expensive.

So another alternative is BitMover, which at the cheapest will cost you $400 a head. But there's also a leasing option that could work out better for you, and you get the warm fuzzies by supporting the software that keeps Linus calm and happy.

Or, finally, you could talk to some CVS consultants. The guys at cyclic could certainly help you out with your problem, and probably more cheaply. At the very least, they should be able to tell you if your problems can be fixed in CVS, and at that point you should have a better shopping list of what to buy in a new system.

I don't know whether you have a source code respository but we manage all our documentation using a combination of our perforce which runs on our linux and windows boxes and having accepted pracices for the use of collaboration tools such as groove and webloggers.
All useful information is stored in a respository and may be accessed from our intranet website. We're investigating using XML to categorise our knowledge base. We do some work on knowledge management so technically the group I work for should be good at this and our current processes seem to work well. Don't underestimate the need to have formal documents emphasising that knowledge is your most important resource and outlining how everyone should achieve it's management.

Perforce's change review daemon is perfect for this. Modify it to autobuild/test each changelist, and email result to the responsible party after completion. The review daemon is written in Python so its pretty easy to read and modify. Perforce has the keys to those pearly gates it seems.

At work we normally use Visual SourceSafe, which, at least in my eyes, has a lot of problems and is definitely not suited for distributed programming.

Recently, however, Ive been using Perforce quite a bit, for a project in which we have three geographically distributed teams (Costa Rica, Utah and California). It is really nice, especially compared to VSS. It is completly multiplatform, very stable, has a nice interface (both winP4 and the command line client), manages branches and merges really well, etc. The only downside I see is that access times are a bit on the slow side, but then again, all of them are here in Costa Rica ;)

We also used CVS a little bit before switching to P4, and it worked well, but I think P4 is a more polished product, specially since not only developers where checking in and out stuff.

Perforce has atomic transactions. Perforce has a slightly biased (but not much) comparison of p4 to cvs. Atomic transactions plus easy administration makes it worth the price for my company.

Perforce has atomic transactions. Perforce has a slightly biased (but not much) comparison of p4 to cvs. Atomic transactions plus easy administration makes it worth the price for my company.

• Smaller. You only need one executable on your client. And one more for your server. No kernel patches, no drivers, no installation, just the binaries. Ubercool.
• Multi-platform. Perforce has binaries for practically every platform in use out there. Find me another Version Control System with BeOS, QNX, AIX, SCO, MacOS9 and MacOSX support.
• Fast, fast fast. Because of the low communication overhead, it works extremely well across slow/high latency links.
• Ease of use. It's really easy to configure and setup.
• Great support. We've had to go to perforce support twice and both times they've been awesome, with quick responses and knowledgeable people.
• Price. The single server, two client setup is FREE! And per seat licensing + support is very very reasonable. I use the free one on my laptop to version files.
• Plug-ins. Perforce publishes their API, and they have perl, python, ruby and tcl utilities galore.

Most of all, I would advise you to educate yourself on the options/methods of version control. 12 isn't that big. Wait 'til you get to 1200.

• Smaller. You only need one executable on your client. And one more for your server. No kernel patches, no drivers, no installation, just the binaries. Ubercool.
• Multi-platform. Perforce has binaries for practically every platform in use out there. Find me another Version Control System with BeOS, QNX, AIX, SCO, MacOS9 and MacOSX support.
• Fast, fast fast. Because of the low communication overhead, it works extremely well across slow/high latency links.
• Ease of use. It's really easy to configure and setup.
• Great support. We've had to go to perforce support twice and both times they've been awesome, with quick responses and knowledgeable people.
• Price. The single server, two client setup is FREE! And per seat licensing + support is very very reasonable. I use the free one on my laptop to version files.
• Plug-ins. Perforce publishes their API, and they have perl, python, ruby and tcl utilities galore.

Most of all, I would advise you to educate yourself on the options/methods of version control. 12 isn't that big. Wait 'til you get to 1200.

• Smaller. You only need one executable on your client. And one more for your server. No kernel patches, no drivers, no installation, just the binaries. Ubercool.
• Multi-platform. Perforce has binaries for practically every platform in use out there. Find me another Version Control System with BeOS, QNX, AIX, SCO, MacOS9 and MacOSX support.
• Fast, fast fast. Because of the low communication overhead, it works extremely well across slow/high latency links.
• Ease of use. It's really easy to configure and setup.
• Great support. We've had to go to perforce support twice and both times they've been awesome, with quick responses and knowledgeable people.
• Price. The single server, two client setup is FREE! And per seat licensing + support is very very reasonable. I use the free one on my laptop to version files.
• Plug-ins. Perforce publishes their API, and they have perl, python, ruby and tcl utilities galore.

Most of all, I would advise you to educate yourself on the options/methods of version control. 12 isn't that big. Wait 'til you get to 1200.

Perforce has a daemon that is run, and it's got clients for Windows and all the Unix clones, free and non-free.

Now, perforce itself isn't free, but some things are just worth the money.

These are the ingredients to make large projects successful from a technical point of view. At the company I work for, we have literally hundreds of people working in the same source tree using P4. It manages merges, versioning, and works flawlessly over the internet (well VPN anyway). It is also much, much faster at syncing to the the depot than CVS because the server keeps track of those files that you are editing and does not need to do diffs with the local filesystem. This is very helpful during crunchtime where you might want to sync serveral times a day (and you have about 10000 files in the system). Also, until your locally edited files are resolved with changes in the depot you cannot submit them, so you don't have the problem of ordering patches properly.

For the second part, I highly reccommend that you have automated build and tests that run after changes have been submitted. You can see how this is done en mass on the mozilla.org site. Also, developers should have access to the same build and test infrastructure on their machines so they can do the build and test before they check in their code.

Finally, you need a good bug tracking system. You might try Bugzilla.

Good luck,
Sam

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.

The data manager implements optimized database services based on the Berkeley DB database package, customized for multi-user support. It maintains a meta-database describing the status and history of versioned files in the depot and transactions against the depot. The librarian is a highly efficient file archiver that stores repository files on disk local to the server. It writes text file versions in an RCS-compatible, reverse-delta format; binary file versions are stored in a standard compressed format.

from the migrating-your-code-repositories dept.

Also from the 16-days-between-submission-and-posting department. :)

I'm still looking around at various source control options. Perforce is the current favorite, owing to a combination of a good feature list and a number of my team's programmers having prior experience with it. The big things holding it back are the cost (over $500/seat/year) and migration time. It's really a different beast entirely, even compared to the Visual Studio CVS plugins.

Nothing seems to handle both binary and source version control well. There are special tools for one and the other, but nothing that's strong on both. I'm a programmer, and I'm tempted to just take care of my own, moving code over to a new tool and leaving SourceSafe in place for the artists. That's not quite as mean as it sounds; artists don't do multiple checkouts, and all off-site access will be read only. Those seem to be the two big things that corrupt SourceSafe.

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.

• Logging: P4 is much more server-centric than CVS, so at any time you can see what files are opened by which developers on which machines, which is one of the things that you're looking for. In addition, the ChangeList metaphor that it uses for atomic changelists ties the whole thing together by allowing you to easily do lots of tracking by changelists. Finally, you can do a lot of reporting with the built-in tools, such as "show me the last 10 submissions by Bob" or "show me all changes to affect that branch of development".
• Branching and Merging in Perforce is great. Fundamentally, it keeps track of the different file revisions as separate subtrees of the system. So, for example, you can have //dev/... (the current development branch), //dev/v2/... (version 2), //dev/v3/..., etc. Or you can have //dev/..., //v2/..., //v3/... You can pick and choose precisely where you have branch points however you choose, and because that mapping ends up affecting the client's file hierarchy, users have the same hierarchy for different versions of the code hierarchy at the same time. Merging is incredibly easy (we currently have 4 active branches of development, and it's reasonably easy to keep them all in sync).
• I think what you want is to be able to see who's working on something. Let's say you've got a binary file checked into CVS. Two people might be working on it. How will they know? Are they expected to email everybody else that they're working on it? What happens when they try to reconcile the changes? P4 handles this by keeping track of who's working on what file, WITHOUT locking the files. So you can have two people working on the same file, but they at least KNOW about it at the time that they're making their changes. Furthermore, for troublesome binary files, you can now have a file attribute on the server say "multiple people can read this file, but only one person can have it checked out." You can control that on a per-file, or per-file-type (such as "all .doc files") basis, which can be huge for the few files that inevitably have those problems.
• I'm not sure what you're talking about with the lack of true version control, but P4 has a very strong transactional background, and perfectly atomic submissions (which CVS does not). It's impossible to synchronize to an inconsistent state without specifically wanting to do it. If you're talking about RCS file corruption, P4 stores digests of all the revisions of all files in the depot in order to ensure that it can recover from RCS corruption (or at least detect it, I'm not sure since we've never had a case of corruption there).

There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.

The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.

• Logging: P4 is much more server-centric than CVS, so at any time you can see what files are opened by which developers on which machines, which is one of the things that you're looking for. In addition, the ChangeList metaphor that it uses for atomic changelists ties the whole thing together by allowing you to easily do lots of tracking by changelists. Finally, you can do a lot of reporting with the built-in tools, such as "show me the last 10 submissions by Bob" or "show me all changes to affect that branch of development".
• Branching and Merging in Perforce is great. Fundamentally, it keeps track of the different file revisions as separate subtrees of the system. So, for example, you can have //dev/... (the current development branch), //dev/v2/... (version 2), //dev/v3/..., etc. Or you can have //dev/..., //v2/..., //v3/... You can pick and choose precisely where you have branch points however you choose, and because that mapping ends up affecting the client's file hierarchy, users have the same hierarchy for different versions of the code hierarchy at the same time. Merging is incredibly easy (we currently have 4 active branches of development, and it's reasonably easy to keep them all in sync).
• I think what you want is to be able to see who's working on something. Let's say you've got a binary file checked into CVS. Two people might be working on it. How will they know? Are they expected to email everybody else that they're working on it? What happens when they try to reconcile the changes? P4 handles this by keeping track of who's working on what file, WITHOUT locking the files. So you can have two people working on the same file, but they at least KNOW about it at the time that they're making their changes. Furthermore, for troublesome binary files, you can now have a file attribute on the server say "multiple people can read this file, but only one person can have it checked out." You can control that on a per-file, or per-file-type (such as "all .doc files") basis, which can be huge for the few files that inevitably have those problems.
• I'm not sure what you're talking about with the lack of true version control, but P4 has a very strong transactional background, and perfectly atomic submissions (which CVS does not). It's impossible to synchronize to an inconsistent state without specifically wanting to do it. If you're talking about RCS file corruption, P4 stores digests of all the revisions of all files in the depot in order to ensure that it can recover from RCS corruption (or at least detect it, I'm not sure since we've never had a case of corruption there).

There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.

The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.

• Logging: P4 is much more server-centric than CVS, so at any time you can see what files are opened by which developers on which machines, which is one of the things that you're looking for. In addition, the ChangeList metaphor that it uses for atomic changelists ties the whole thing together by allowing you to easily do lots of tracking by changelists. Finally, you can do a lot of reporting with the built-in tools, such as "show me the last 10 submissions by Bob" or "show me all changes to affect that branch of development".
• Branching and Merging in Perforce is great. Fundamentally, it keeps track of the different file revisions as separate subtrees of the system. So, for example, you can have //dev/... (the current development branch), //dev/v2/... (version 2), //dev/v3/..., etc. Or you can have //dev/..., //v2/..., //v3/... You can pick and choose precisely where you have branch points however you choose, and because that mapping ends up affecting the client's file hierarchy, users have the same hierarchy for different versions of the code hierarchy at the same time. Merging is incredibly easy (we currently have 4 active branches of development, and it's reasonably easy to keep them all in sync).
• I think what you want is to be able to see who's working on something. Let's say you've got a binary file checked into CVS. Two people might be working on it. How will they know? Are they expected to email everybody else that they're working on it? What happens when they try to reconcile the changes? P4 handles this by keeping track of who's working on what file, WITHOUT locking the files. So you can have two people working on the same file, but they at least KNOW about it at the time that they're making their changes. Furthermore, for troublesome binary files, you can now have a file attribute on the server say "multiple people can read this file, but only one person can have it checked out." You can control that on a per-file, or per-file-type (such as "all .doc files") basis, which can be huge for the few files that inevitably have those problems.
• I'm not sure what you're talking about with the lack of true version control, but P4 has a very strong transactional background, and perfectly atomic submissions (which CVS does not). It's impossible to synchronize to an inconsistent state without specifically wanting to do it. If you're talking about RCS file corruption, P4 stores digests of all the revisions of all files in the depot in order to ensure that it can recover from RCS corruption (or at least detect it, I'm not sure since we've never had a case of corruption there).

There are even tools for automatically taking a CVS hierarchy and putting it into P4. I've not used it, but apparently it's quite easy to do.

The biggest change that people I've seen always notice is the fact that with CVS, you just start editing files and it'll figure out later how to work that into the server. With P4 you have to tell it, which is not that great. However, there's a tool called C4 which a couple of our engineers who are most comfortable with CVS use which presents a view almost identical to that of CVS (except for the specific P4-isms), so that the learning curve is greatly decreased.

We standardized all our early documentation on XML, and it's been working great. Admittedly we're using Perforce, not CVS, but we're doing something very similar to what you want to do.

All our documentation is in XML format, in a DTD that we defined. We then have XSLT transformation scripts that convert that documentation to HTML format, and scripts that automatically update our development intranet whenever changes get checked in, along with scripts that invoke javadoc and doxygen on all the code to convert that to HTML format. We're in the process of being able to convert the same documents to PDF format to be able to publish those same documents, in the same formatting, to pretty-formatted documents for printing.

This, aside from the simplicity of not having to worry about formatting documentation when you write it, is pretty cool. It's easier for me (as an engineer) to write a very sparse, structured XML document that will end up looking very good on screen, than to learn enough HTML to make my documents look good. And it's easier for us to enforce a standard look and feel across all documentation this way, because only the XSL transforms have to change if we change our formatting.

But the real advantage is coming out with more advanced uses. For example, when we have configuration files, we have a special DTD that we define the documentation for the configuration files in, and then any documents that describe the configuration files are automatically converted both to the HTML documentation, AND to an example configuration file for users. We can also mark some things as only visible internally, so that the same document can have data that's visible to end-users, and data that's visible to employees (so if we have advanced configuration options that we don't want customers mucking with because they're for debugging the system, we can document them in the same place, and just hide them from customers but let our support and professional services people in on the secret).

The best part is that because our XML DTD is very structured, someone like me (an engineer), will actually use it because it ends up being easier for me than writing in plain text, whereas I wouldn't do it in HTML (or if I did, it would just look like crap). It also makes it much easier to do integrations across branches of code: because we know the DTD for our XML documents very well, it's more likely that integrations will go smoothly, which helps keeping multiple branches of code and docs in sync automatically. If you go with a binary format, you're not going to be able to do that, and every time you make a change, you're going to have to manually change the documentation for each and every branch. With ASCII or HTML, everybody's going to produce documents that look a little different, so you're not going to be able to have as easy a time in integrating between branches.

Our docs infrastructure person can pipe up in terms of the particular technology that we're using, but it's turned out to be one of the best infrastructure decisions that we (actually, she) made, and it's saved uncountable hours and actually made it more likely that people will write documentation themselves, because they don't have to pull out some crazy windows tool: just edit the document in emacs, and it'll still look pretty for the customers.

You should mention to Linus that Perforce is giving free licenses to Open Source developers; the GNU GPL v2 or higher is sufficient.

Perforce is very flexible, a great system. Plus there's a great user community.

One advantage Perforce has over CVS is it groups a number of files into a "submit". A submit is atomic: if anything goes wrong it rolls everything else back. Change numbers describe a submission, then, not a single file. This is very useful -- you can see which files a person touched at once, either to see how he was thinking while working, or if maintenance is required, it's easy to find all the changes that went into his contribution to the source tree -- there all described by a single change number.

If Linus hates CVS, why not set up a Perforce server for him? I was recently looking at their web site, and saw that Open Source developers can obtain licenses for FREE!

It's more powerful than CVS, and has a great user community to help solve problems.

I just downloaded it, installed it, and started submitting files in about an hour -- and half that was the download (modems suck, especially after having had ADSL, 1-way cable, and 2-way cable).

No relation to Perforce, just very pleased with their interface and their attitude.

We use perforce here at work. It's got client binaries for *nix and Windows, and using it is no harder (once your 'view' is setup) than typing "p4 edit {file}" or "p4 submit {file}". Breezer. Cost is, well, I'm not sure, but I just use the tools, I don't really buy 'em. :P Check Perforce for more information. It works well, we've never had problems with it, so based on that I can endorse it.

Apple is the penulitmate closed OS. Not only will they not publish the source code (understandable for a corporate effort), but they don't want you developing for it unless you only use what they give you, which seems to be less than even MS does.

First off, they have opensourced everything but the GUI of OS X.

Second, _every_ copy of Mac OS X comes with a copy of the latest version of the development tools that NeXT used to sell for thousands of dollars. Not only that, but the IDE is just a GUI sitting on top of Jam and GCC (currently 2.95, but they just got 3.0 building & have been submitting their changes back to the FSF).

Seems to me that they have gotten VERY developer friendly lately.

I am not using perforce now because it is too expensive, however Perforce is free when used on open source projects, or when only two clients are needed. This is outlined on the perforce pricing page.

We've been considering both Visual Source Safe (which we've had good luck with, but find it feature-poor) and CVS. I'd love any feedback anyone has comparing the two on a fairly large project, particularily where we have two sets of developers working off-site through slow IP links.

PVCS was appallingly bad. Random corruption, files perpetually locked by others. RCS was feature-poor. CMS was actually pretty good, especially if you didn't want to branch anything. I used to like CVS.

Then I landed in a shop where they use Perforce, and grumbled for a while that it wasn't CVS. Pretty quickly I was a convert. Perforce is like CVS except that:

• branching is understandable
• the commands and options are regular and systematic, so it's possible to remember what they all do
• it has lots of reporting commands, so you don't have to maintain a ChangeLog by hand

Then I discovered how much fun scripting it was!

There's tension in that it's not free software, but then Perforce the software and Perforce the company are a joy to deal with, so you don't begrudge them all that much. Their user base is largely a free software-like rabid bunch of happy advocates, so something must be right.

I'm looking forward to next week's SVLUG talk about Subversion, which might be Perforce's first real competition for a while in the "it's not ClearCase -- thank God" category.

Over the slow IP links: by all accounts, Source Safe is terrible. On our large projects worked on from half a dozen sites, Perforce works well. The GCC folks can probably tell you how well CVS works in that situation: I suspect the answer is pretty reasonably well too.

I'll put in two cents worth for Perforce. The open source version of the BeOS Tracker uses P4 and it works pretty well, although it's not free.
CVS, on the other hand IS free and it also works wonderfully. Good luck with that troll infestation at your office.

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.

If you use CVS or RCS to manage your source trees, moving to Perforce will not be that much of a stretch since your nightly build scripts will not need much tweaking (you do have nightly builds, don't you?). Indeed there is at least one CVS-style frontend to Perforce available from their website.

Perforce's big wins over CVS:

• atomic checkins: either all files get updated or none do
• integration records: you can tell where a revision was branched/merged to (and from!)
• handling of deleted files is less clunky

I am never going back to CVS, Perforce wins hands down (and, yes, it's available for Linux (and *BSD too)).

I've used CVS, PVCS, VSS, (but not ClearCase), and Perforce is the best system I've ever used, bar none. Let me go through some of the key points:

• Quality of Support. I put this first becuase I think it's that important. I get same-day turnaround whenever I contact them and it's not a weekend (and I've gotten turnaround within an hour at 1am on sunday, so even then you often do), their tech support people know what they're doing and are willing to go the extra mile.
• The Model's Like CVS. I think this is actually important. To get all the "advantages" of clearcase, you have to be using the ClearCase file system, which basically means that your compiles are over NFS. Do you really want that? P4 gives you a local copy of all the files, just like CVS.
• Server Centric Model. While this can impose some difficulties for fully disconnected access, it saves your ass in a lot of places. Thinking of deleting a file and want to know if someone's working on it? You can see. Thinking of doing a branch and want to see the status of the branch on people's current machines? You can see. This can save you quite a few times.
• Multi-Platform Support Rocks. I've NEVER found a platform which P4 doesn't support. Mac, Win, Linux (we're using it on Intel and Alpha), Solaris, even IA-64 if you've got one, they run on everything. Very nice.
• Ease of Use. If you've got people who are familiar with ANY local-file based source control, they can be up to speed extremely quickly. I've got people who are familiar with CVS who are working extremely well in like 2 hours with P4, rather than weeks of training in CVS. So your training costs are virtually nil with P4 if your people already know CVS or VCC.
• Speed. It's FAST. REALLY fast. Because of the server-centric model, it's able to determine extremely easily what you need to download and what you don't. It uses things like MD5 digests to determine whether you're actually in sync, it uses its database of what you've stored, etc. And then it just downloads a compressed delta of the file and modifies it locally. If you've got people working over not-so-fast links, this will save your ass.
• It's TRANSACTIONAL. The basic unit of transactions is the Changelist. When you check stuff in, it's completely atomic. Either everything's submitted, or nothing is. That's it. So at any time you have, without labelling, a complete, transactional history of everyting that you've ever done, and it means that you can never download in inconsistent states. Everyone is consistent all the time. This also means that you don't have to constantly label everything, because the transaction ID acts as a unique identifier for the state of the database at any given point in time.
• Branching/Merging Rocks. I've never had a case where P4's branching/merging support didn't work perfectly. They detect three way merges, they detect multiple lines of integration/development, it all just WORKS. I can't stress how important this is for quality development, and it's infinitely better than the support in CVS.
• Ease of Administration. I administer 2 perforce servers. I spend, on average, about 2 minutes doing administration. The thing just works perfectly.
• Cheap Hardware. Unlike Clearcase, you can get a fairly cheap box for P4. We're running 25 users with about 70 clients on a $5k box (and most of that is RAM and RAID array), and it's so fast that most people never even notice, because its downloads are about as fast as a filecopy on the network.
• Stores in digested RCS files. So it gets around the corruption issue with some tweaking, but the core files are basically RCS files, which means that if you decide to give it the boot for whatever reason, you can integrate them into another source control system very easily. CVS will have the same issues with corruption that VSS does, because they dont' attempt to deal with the problems that RCS file corruption can incur.

I think of Perforce as "CVS on steroids", because it offers so much more power:

• there is fine-grain access control on the repository, on a per-user, per-group, per-IP, per-pathname basis.
• extensive meta-information is kept: both forward and backward integration records
• the server keeps a database of files being edited in every client view, so you know what everyone else is working on.
• automatic merging between branches actually works (I never trusted rcsmerge or cvsmerge, I use perforce's "integrate" all the time)
• it is fast
• repository changes are guaranteed atomic. Nothing is ever half-submitted
• changes (across the entire repository) are sequentially numbered, so each change can be uniquely identified (and changenumbers are like timestamps measured in the change domain)

Perforce uses "Inter-File Branching" (tm) when it branches, and RCS format for its repository files. There's a white paper on their web site describing it, but basically this means that when you branch a file (e.g. from revision 1.2->1.2.1.1 in CVS), you create a new filename in the repository. It may sound hokey, but it works better, IMHO. For one thing, it eliminates the forward deltas in the ,v files. Which means you get rid of the O(n^2) behaviour of RCS/CVS when trying to retrieve branches.

[I have no affiliation with Perforce other than being a very satisfied customer.]