Clearcase vs. CVS? 50
briany asks: "I have been asked to evaluate Clearcase vs. CVS. I am wondering what kind of experiences people have had (good and bad) with either product, or if there are other products that should be considered.
The projects that will be stored are rather large (10+ GB) and need to be accessible from Solaris, Linux, and NT/Win2k." Of course, it should be mentioned that Clearcase is available for Linux, as well as other unix clones.
Order a free demo of Clearcase (Score:2)
my experience... (Score:4)
Clearcase cost a LOT of money and takes quite a bit more administration. For your trouble, you get file locking. Yes, that is sarcasm. No one on the team who was using it at the time liked it.
cvs simply requires a little more developer time to do file merging. I personally really like it.
A rather sketchy testimonial (Score:5)
For what it's worth, I understand one big difference is that clearcase automates things like tracking the compiler and lib versions, so you could go back a long long ways to reproduce a really old version byte for byte. Another difference is that it eliminates dup copies of source and object files among the staff, potentially saving space and time. How well this works in practice, I don't know, and I've never felt any need for it.
The other comment about needing more sysadmin work is certainly true. In addition to the loon who clobbered my system with the bad install (Sun OS, early 90s), a different sysadmin, purportedly her boss, twice erased the entire clearcase repository. Apparently it was too tricky for the average bear. I see that as two strikes against clearcase just from the point of not being very maintainable, and hope to never see it again.
CVS is good. Text files you can edit in an emergency or just in readonly mode to see when things happened, as opposed to SCCS, and it is just plain good. Be happy with CVS. Your repository is valuable -- don't give up control.
--
size info ? (Score:3)
I have installed it and am running it where 20 developers are using java/jsp and it works fine for our product. Images can be a bit annoying, but all text data rocks!!!
Now about the size of your project ? 10G+ was it ? ? exactly what are you going to be storing ? ? Thats a whole lot of code, and as i keep telling ppl. here, data does not belong in the repo..... only code that you want to get back to.... DATA should be kept on a FS with good naming, like a simple (filename)_(date)_(version).* BUT ten G's is going to be one hell of a freaking checkout!!!!
Working in such an env., 10GB+, NT/UNIX clients (Score:4)
I'm working in such an environment myself, Linux server (actually a NetApp filer hosts our repository now, but pserver still runs on the Linux box for NT clients) and NT, Linux and Solaris clients. As a startup, we could not afford a pricey, commercial VCS, and with what we do, CVS was a perfect fit (yes, I have used a number of different, "pricey" systems before). We are a fabless semiconductor firm, so we often have large, textual files (as well as small). CVS works very well for us, and is easy to administer once you get familiar with it. There is no issues with NT and UNIX clients, CVS handles them all of them from the server side, assuming you run CVS in pserver client/server mode (from at least for the NT clients).
Your sole documentation for CVS (other than the occassional Google search) will probably only need to be the Cederdqvist CVS Manual (here in HTML) [durak.org]. If you aren't too familiar with CVS yet, you'll want to play around with a test repository while reading this manual for a month. Trust me, that is what I did the first time around.
In a nutshell, here are my recommendations for a CVS setup, with large files and a both NT and UNIX clients:
[ Note, there is a TkCVS client for UNIX, but it is _way_outta_date_. So don't use it except for possibly looking a work file status as well. In the case of both WinCVS and TkCVS, there is a _lot_ to be said about sticking with the CLI CVS client when checking in/out files -- I don't trust the GUIs to be flexible enough with anything but "browsing" the working files, but that's me. ]
[ Side note: If your setup and workflow is anything like mine (e.g., either NT or dual-boot NT/Linux on desktop, Solaris workstations in a lab), and an X-Server for NT is too expensive, you'll probably want to investiage Virtual Network Computing (VNC) [att.com]. VNC on a UNIX server (as compared to just using it as a simple pcAnywhere type setup on Windows servers, as most people do), is powerful. It is how we have ~10 different engineers running full GUIs on a single Solaris or Linux workstation, each with their own X-session (:1, :2, etc...). Then you simply connect from the Windows client and tada, a full X-session -- that even stays up when NT crashes! Or can be "shared" by Microsoft NetMeeting. Just thought I'd mention VNC since you probably have the same situation/setup I do. ]
-- Bryan "TheBS" Smith
have you tried BitKeeper (Score:2)
Check out http://www.bitmover.com/bitkeeper/ [bitmover.com]
More details? (Score:1)
For what it's worth, I'm currently responsible for the use of ClearCase in our division (not the installation etc., that's left to IT). (We/I'm trying to find someone to take over - I'm a developer, dammit!)
It does require more effort to set up initially, but once done it can be more or less left alone - a few hours a week is the most I've had to do to it in the last few months, IIRC. It's far more useful than CVS, at least IMO. I wouldn't want to try and switch us over, I don't think it would fly.
Clearcase (Score:2)
You can't escape their god-damned tools if you want to. It requires a full time IT staff to administer. You have to build an entire layer of tools on top for it to be usable. The benefits compared to simpler, lighter-weight solutions do not outweigh the disadvantages. I can't think of a piece of software I loath so much, with the possible exception of RealPlayer.
Depends (Score:1)
CVS is better otherwise (easier to administer, faster).
If you have a big team (i.e., you'll want exclusive checkouts to keep them from tripping over themselves) and/or a team in multiple locations (i.e., you'll need something like Multisite/Clearcase), you should go with Clearcase. Otherwise, give CVS a shot. If you don't like it, migrate to Clearcase later.
Re:size info ? (Score:1)
I used both but must admit that Clearcase has the shout when it comes to LARGE corporate projects. When it comes to parallel development in large teams, it really comes into it's own. But don't get me wrong. CVS is excellent too. It just depends on what you're after. Clearcase is a big beast to administer and anybody who contracts in that market knows the money is good.
People tend to forget when comparing these two that there is more than just version control to Clearcase. As well as the delta saves, branching capabilities etc. it also uses derived objects to determine the rebuild strategy instead of timestamps. This means it can reuse objects built by other people which it knows is the same ones you would get in your configuration, but without the need for rebuilding them.
It also supports parallel builds across multiple machines, although one could argue that you could do this with CVS using the parallel build features of GNU make and other technologies.
Also, many large corporations use an awful lot of other tools (like Rational Rose, Clearquest, VC++ etc.) which all integrate nicely with Clearcase. CVS doesn't do this to that extent. If you're an open source house, you will probably find that CVS DOES integrate nicely (take KDevelop as an example).
It's all swings and roundabouts until you put a firm specification on the table which maps out your needs. Until then, the comparison cannot be made.
Re:Clearcase just rocks! (Score:1)
My experience (Score:2)
Right now I'm working on a much smaller development project, only 20 people in one office, and you just can't justify the expense of ClearCase for such a small project, so we're using CVS. Frankly, I'd rather have ClearCase.
My main objection to CVS versus ClearCase is that the support for branching in CVS sucks. Sure, you can branch, but every time somebody makes a change in the main branch, even in files you haven't touched in your branch, you have to merge the changes into your branch. In ClearCase, if you haven't modified a file in your branch, then you see the one in the main branch all the time, even if it changes. This means that unlike CVS, you don't have to run nightly cron jobs to keep merging everybody else's changes in area "A" of the code into your project that is only touching the code for area "B".
Besides that, the other thing I miss about ClearCase is the "-merge -xmerge" functionality for graphically resolving merge conflicts.
ClearCase's "winking" business I can do without on a small project like this. On the one where I was using ClearCase before, a full compile with no winking in took about 20 hours, so winking was a useful thing.
Re:Working in such an env., 10GB+, NT/UNIX clients (Score:1)
1) CVS's storage of binary files.
2) I prefer to put CVS on a Unix server, and they want it on NT.
If I put it on a unix server, is there a problem with put the repository on an NT server via a samba share?
Cost and Support Requirements (Score:1)
pro ClearCase (Score:5)
But it is so much more elegant than CVS if your use of version control is at all sophisticated! (Which, if your development effort is even medium size, I would argue it should be--this is stuff that pays off. But that is a separate discussion.)
For starters, there are some simple correctness issues. Clearcase tracks files across renames, which I gather CVS does not. Moreover, it versions directories, so if you look at an old view of the repository, you see the old names. This allows everything from corrections to badly chosen filenames, up to reorganization of the repository, without any fuss.
Clearcase also has a "findmerge" command with "common ancestor" support. This basically means, when it's time to merge, you always know exactly what you need to merge, with previous merges taken into account. I honestly don't know how you could live without this. (Note this is distinct the tool that actually performs merges, which is nothing special--I just use GNU diff3, myself.)
Second, clearcase has (to me) a killer feature, filesystem support. This means that that you get an ordinary-looking unix filesystem that automatically gives you the latest versions that you're interested in. Further, using an "extended" filename syntax, you can look at any version right from the filesystem. So if you want to see what's going on in the foo branch, you just vim code.c@@/main/foo/LATEST, or if you want to figure out which mainline versions use the fooble API, grep fooble code.c@@/main/*. This is addictive. NB: the filesystem support is not available in Linux :-(
Third, clearcase is very unix-friendly. While this is not a major difference with CVS, it is still worth pointing out (since many commercial products "don't get" unix). Most clearcase commands are close to their unix analogs (or in the same spirit, when there is no analog), and the documentation is in man pages. For me, this made learning clearcase easy, and adds a significant comfort factor.
To me, version control is not just about making sure I can work on my stuff without getting stepped on by anyone else. (CVS is fine for that.) It's also about expressing, understanding and managing the relationships between various versions and branches. This is a conceptually more difficult activity, and I frankly think many posters here don't see its value (it takes a while). But if you do, clearcase wins hands-down.
I admit that, while I have used CVS, I have only had day-to-day experience with clearcase (and Visual SourceSafe--bleh!), so I don't have a good sense of the "CVS routine". It perhaps includes some practices that mitigate the lacks I've cited. But, as long as someone else is taking care of the cost and administration and resources (under these circumstances, I have found clearcase reliable, if still a bit pokey), and I don't have to interoperate with outside developers who don't have clearcase, I would take clearcase in a second.
Re:size info ? (Score:1)
Data most certainly needs to be revision-controlled.
Data/config files, images/icons, documentation, anything that goes into a release needs to be under control. If you ever fix a bug in a product you want to be able to build the identical file-set that went into that project. Over time, data files get updated, images/icons change, and if you have to go poking around on backup tapes for the original images, you are wasting time. I've worked on several large commercial products using ClearCase and EVERYTHING went into the database, even directory structures (something I wish you could do for real with CVS).
Re:pro ClearCase (Score:1)
Disclaimer: I work as a ClearCase support Engineer for Rational, I may be seriously biased in anything I post in this thread!
EZ
'The truth is out there.. but the lies are all in your mind.'
Subversion (Score:2)
Subversion looks to be a promising, well thought out, version control system, incorporating the major features of CVS, but also adding and simplifying/clarifying/refining some features (directories can be versioned also, finally; merging and ancestry is also cleaned up and simplified).
http://subversion.tigris.org/
A detailed design doc describing the various layers, and example diagrams of branching and merging, and various other goodies is at:
http://subversion.tigris.org/svn-design.html
CVS is just barely good 'nuff...but it really feels incredibly hackish. I think it's about time there is a well thought out version control system, built from the ground up, independent of any legacy stuff like RCS.
Re:pro ClearCase (Score:1)
Re:pro ClearCase (Score:1)
thank you thank you thank you thank you! Looks like I have something to do this weekend!
(And I'm sure I will have a great time trying to build a kernel that it likes, since I run Debian. Note to rational: you should create a system that allows a user to upload a kernel tarball and automatically compiles your modules against it. Unsupported, of course.)
Visual Source Safe (Score:1)
Consider Perforce... (Score:1)
Re:pro ClearCase (Score:1)
I use ClearCase daily (I do the merges/integration/releases) and I'd hate to use anything else. It supports concurrent development better than anything else I've seen.
The point that you leave out about ClearCase is the learning curve. I work with folks who have used it for years and still don't quite get the differences between branches and views. It is without a doubt the most complicated configuration managemnt philosophy that I've ever seen. But I think it is worth it.
- doug
PS: I agree 100% with you about VSS. It is pure crap.
[*] ClearCase now (since 4.0) has something called a SnapShot View that seems to have the same basic functionality. I've never used it, so I can't say for sure.
Re:My experience (Score:1)
Only a system that fully understands the relationships between the derived file and all its source files (including not only a .c, .s, .f, and included files, and so on, but also the compiler, its version, options used to compile, etc.) can do this kind of thing sufficiently safely.
Otherwise developers would risk having the too-frequent need to try debugging things that turned out to be subtle differences between using a winked-in derived file vs. one built from scratch by a given developer.
ClearCase handles most of that stuff. But, IIRC, we had to deal with the occasional instance of ensuring we were not chasing down a bug due to winking a particular developer's derived file, or a particularly sensitive derived, file, in versus having it built from scratch.
And doing that required disabling winking-in for a build, at which point the (apparent) overhead of ClearCase became, well, annoying -- though I don't have enough expertise to really know how much of that overhead was due to other things (NFS and other servers, for exaample).
PLEASE consider perforce. (Score:4)
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'm a little partial, but it's an amazing system that you really should evaluate. I think that if you're looking at CVS and ClearCase, P4 gives you the happy medium: faster and cheaper than ClearCase, more enterprise-friendly than CVS.Re:Working in such an env., 10GB+, NT/UNIX clients (Score:1)
While it's not ideal space-wise, you can check in binary files by adding them with the "-kb" flag, as in cvs add -kb binary_file. Older versions of CVS might need you to use "-ko" instead.
If you accidentally check in a binary file w/out "-kb", you're ok until try to check in an update to the file. In that scenario, you can use cvs admin to fix your boo-boo. See the Per Cedarqvist manual for details.
--Joe--
Branching and modules (Score:1)
If the two areas are really that distinct, so that you know your changes will compartmentalized, then you can solve this by making the two "areas" be CVS modules, which will keep their own separate branching history. So your code tree is made up of two modules, one on a main branch, the other on your private development branch.
If they are really extremely disconnected, then you might even keep them in different repositories.
Re:Cost and Support Requirements (Score:1)
Given this though I have to aggree that Clearcase is not the optimal solution for small groups of developers regardless of the Storage requirements. It's main power lies in its MultiSite component and binary abilities. Note that CVS can store binaries but can not do diffs of them. The ONLY real reason I have seen for anyone to put binaries into the repository is for Windows Developers that were strictly required to keep VERY thorough documentation in MS Word format. The repository makes sense for this in that the Documentation is as easy to get to and update as the code itself.
Just my 3 cents worth....
Re:Branching and modules (Score:1)
Re:PLEASE consider perforce. (Score:1)
CVS doesn't understand that multiple files can be part of a signle atomic change. This is the biggest failing in CVS. If I change a function's interface, I'll probably also change the calls to the function to use the new interface. This change should be able to be backed out or applied completely atomically. P4 lets you do that. CVS keeps a history of each file, while P4 keeps a history of each change. A subtle, yet importantant, distinction.
Re:Branching and modules (Score:1)
One thing that I sometimes did is make a separate repository local to my system for extended work on something, and then only put the end product in the main project repository.
With ClearCase, do you have a local copy of the code at all ? I was confused by some of these references to a clearcase file system, and of the build process being integrated to the point that it took other developers object files instead of recompiling provided it met the dependancies. Can you work disconnected from the "repository" ? I used to check out code onto my laptop, work on it on a plane trip, and then commit it from my destination. Would I be able to compile if my machine couldn't talk to the repository ?
Look at Perforce (Score:1)
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:
I am never going back to CVS, Perforce wins hands down (and, yes, it's available for Linux (and *BSD too)).
Clearcase (Score:1)
Technically, CC has one major advantage over the vast majority of CfgMgt tools: directories are just another element being managed.
There's a slew of minor cutes - such as winkin; decent branches; a workable multisite solution; very powerful triggers and the choice of dynamic or manually updated views.
There are a few technical downsides: on NT/W2K the registry use is opaque (very hard to do something non-standard w.r.t usage model); the API is proprietry (no 'use ClearCase;': I write lots of 'qx+cleartool...+')
Commerically, it has been reliable; it is feature rich; supports wizards and a CLI; well supported (good manuals and good technical support); and robust. There's a large user base with lots of experience which means that it is .
I didn't say it was cheap. But it's cheaper than a man-month of lost schedule.
It need not be difficult to maintain. There is an admin learning curve. (And the 'Rational U' exists for exactly this reason.) There is absolutly no excuse for "it lost all my data". (Is anyone seriously suggesting that you need't backup prior to letting a newbie install an unknown CfgMgt tool?)
Summary
If you want CfgMgt but don't want to spend cash, use RCS or write one.
If you have a commercial environment and a team of more than one person, then it is worthy of serious consideration.
Personally, I've been very happy with it.
CD.
Re:Subversion (Score:1)
Subversion is shaping up nicely... Ive been monitoring it for a while now. It will be what cvs should have been years ago. When people start using subversion they will never want to go back to cvs.
--John Cavanaugh
So slowwwww.... Zzzz... (Score:1)
link on separate hosts mounting the views with the
MVFS feature : a network filesystem crossed with a version controlling system. It's quite funny since you can access versionned files just like regular unix files but it can cost a lot !!!
Here are some performance measurements for a medium size file written in C...
1) clearcase view:
real 2m29.403s
user 0m10.630s
sys 0m25.653s
=> cpu = 36.283s / wait = 113.120s
2) Local partition:
real 0m13.522s
user 0m8.911s
sys 0m3.391s
=> cpu = 12.302s / wait = 1.220s
Running uptime on the VOB server and the compiling
host reveals that the compiling host is often idle, waiting for the overbusy server (cpu 100%) to complete VOB requests...
Be idle with clearcase !
Clearcase vs CVS vs Perforce (Score:1)
Re:Working in such an env., 10GB+, NT/UNIX clients (Score:1)
You can find most of the book online here: http://cvsbook.red-bean.com/ [red-bean.com]
Also consider ODE (Score:2)
You might also take a look at ODE [ede.com], the OSF Development Environment. Like CVS, it's layered on top of RCS. I beleive it has more support for branching than CVS.
Tom Swiss | the infamous tms | http://www.infamous.net/
Clearcase VS CVS (Score:1)
Responsibility for merges (Score:1)
Re:pro ClearCase (Score:2)
Re:Clearcase (Score:2)
Rational Hell (Score:2)
Some have talked about wonderful "visual" merges. Frankly, if you're using branches that much and doing that much merging, you are over doing it. Merging branches is time-consuming and fraught with potential gotchas. I suggest finding a new development process that will avoid those problems (like XP). Anyway, you can visually access branches on CVS if you use a free client like WinCVS. It's great. Makes dealing with a CVS repo just like dealing with your file system.
Using ClearCase will likely lead you down a bad path of more complicated development processes. And that is a bad thing. Keep it simple.
The rest of Rational's toolset isn't much better. Our requirements people use Requisite Pro to store requirements. The development group is always asking them to see the requirements (duh!), but we don't have requisite pro, so we never seem to get them. They always say they can print out versions that we could see, but what they do print out or send us doesn't display right in Word or whatever, and usually they just can't be bothered to do the work necessary to output a format we can read. If they would just use a simple program, things would be so much easier...
They say developers are nuts for stupid toys - at least our stupid toys don't cost everyone time and money!
Both have their strengths (Score:1)
Clearcase's graphical tools, like the graphical merging tool, and the ability to see and compare branches and versions from within their gui is definitely a bonus.
The ability to merge clearcase with DDTS bug tracking was a definite pain in the ass. At least the way our CM management set it up. ("You mean I have to register and be assigned a software defect just to add a new feature???")
Managing labels can be a pain, especially when the nightly build breaks, and you need a new feature that was introduced in that build... Again, make sure your clearcase admin knows what they are doing or you could have a nightmare with the precedence that labels are searched to find "your" version)
I've just recently used CVS on a couple of small projects with just a handful (5) developers. The definite advantages are that almost anyone can maintain a CVS repository, and you still get some of the branching and merging features, but they seem to be a bit more crude than clearcase features. (Though clearcase can be pretty dumb with the auto merge. Have two developers add identical versions of the same function in two different locations in the same file, and it's happy to merge them both in without a peep.)
I've hit some weird snags with things like scripts that worked on Solaris, but broke on cygwin/NT because the binary flag didn't get set in CVS. I've also had directories that I couldn't remove from the CVS repository, and kept reappearing with every checkout. Probably just due to limited exposure to CVS so far...
Anyway, CVS's main advantages are the price, and its ease of maintainence. On the down side, support for gui interfaces to it don't seem to be standard across platforms. What gui you really like for linux probably doesn't exist for NT.
If you have the monetary and support resources to handle clearcase, it may be worth it. But if the price is just too scary, or your project just doesn't seem big enough to warrant it, then CVS is a good tool that should help meet your needs with a much smaller price tag.
Re:Both have their strengths (Score:1)
The ability to merge ClearCase with DDTS bug tracking was a definite pain in the ass. At least the way our CM management set it up. ("You mean I have to register and be assigned a software defect just to add a new feature?")
I set up something similar between DDTS and good 'ol SCCS. By turning on the "MR" flag in the s-file, and specifying a script as the "validation" program (which, in my case, didn't have to do any actual validation), every file check-in logged itself to the proper DDTS entry. True, the DDTS entry had to exist first, but that was no problem in practice -- to add a new feature, just create a new DDTS entry, assign it to yourself, and log any changes there. Recording new features in DDTS also gave us one central source of info when it came time to write the documentation on "what's new in this release".
Integrating the version control tool with DDTS was so simple that, in my opinion, any version control tool which can't do that easily is broken and should be rejected.
XP is NOT a panacea (Score:3)
What about stable release lines? Your team might have already started working on 2.0, but now you find a bug in 1.1. You expect all your customers to take an unstable 2.0 version? (and don't give me all this "always ready to ship" crap....if you don't have all the functionality ready, you're not ready to ship). You need to have multiple branches from there. Without good branch capabilities, you can't merge the fix in the 1.1 line with the 2.0 development.
So you're saying that you NEVER branch, and thus NEVER merge? How do you handle long-running projects? Projects with multiple releases? Projects with 100 developers?
I agree that complicated processes are bad. But processes should be there to help developers do their job. A good source control system with good branching and merging helps you when you need it.
Re:Cost and Support Requirements (Score:1)
Re:XP is NOT a panacea (Score:2)
Creating a separate branch for each develoment team, though, strikes me as nightmarish (though, it's not as bad as the clearcase way of separate branches for each *developer*). If you have 100 developers working on the project, I would hope the project has enough sub-packages to warrant it. What does the branching get you, anyway?
If you create 5 branches to let those 100 developers work concurrently in them, then how do you know their code will merge well? How do you know the merge won't result in the introduction of bugs (and bugs caused by such large merges are very hard to find)? If your answer is that the development teams must communicate effectively, then I would say, if they were communicating effectively, then branching wasn't necessary in the first place.
Re:Both have their strengths (Score:1)
We had some horrible policy along the lines of "A developer can create an entry. A manager must then assign that entry to the developer who entered it." And so on... whoever configured the system required a manager's approval to do almost everything.
The one hole they left was that the developer could change the person who received all the checkin/checkout email for the clearcase branch. So you wait till someone takes a day off, and bombard them with a checkout/cancel of the entire source tree...
Re:Visual Source Safe (Score:2)
As for version control, I only know VSS. So I'd like people to comment (rationally, I can flame Microsoft myself) on its advantages and disavantages, relative to other products.
We are a small team (< 10) and all in the same building.
As for disavantages, I can say that I tried to move teh database to another machine and the only way to get it right was deleting all local data and getting the lastest version from the new location.
__