Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Making Sense of Revision-Control Systems

kdawson posted about 5 years ago | from the only-constant-is-change dept.

Programming 268

ChelleChelle writes "During the past half-decade there has been an explosion of creativity in revision-control software, complicating the task of determining which tool to use to track and manage the complexity of a project as it evolves. Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial. It is important to keep in mind that whether distributed or centralized, all revision-control systems come with a complicated set of trade-offs. Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works. This article outlines how to go about finding the best match between tool and team."

cancel ×

268 comments

Sorry! There are no comments related to the filter you selected.

Perforce (1)

saccade.com (771661) | about 5 years ago | (#29194411)

We've had great luck with Perforce for several huge projects. I use it at home for smaller personal work too. It's excellent (no connection with the company, just satisfied customer).

Re:Perforce (1)

ZeekWatson (188017) | about 5 years ago | (#29194459)

P4 is awesome and works great for huge repos with lots of developers.

However it is getting stale. I can't think of a single new feature added to it since I started using it in 1999.

Re:Perforce (4, Insightful)

xmundt (415364) | about 5 years ago | (#29194589)

P4 is awesome and works great for huge repos with lots of developers.

However it is getting stale. I can't think of a single new feature added to it since I started using it in 1999.

Greetings and Salutations...
          Funny...I tend to think of software more like a truck than a stalk of celery, so, staleness really never popped up on my radar. What new features would add to the capabilities of a package that you describe as "awesome"?
          Not flaming, I am really curious, as I have done some software development myself, and, wonder where the line is between actually adding good functionality to a tool, and "creeping featuritis" that adds bells, whistles and complications, but no real increased usability.
          regards
          dave mundt

Re:Perforce (2, Interesting)

ZeekWatson (188017) | about 5 years ago | (#29195757)

Off-line development is the first thing that come to mind.

Its also single-centrally managed server, which is painful for distributed development (but perhaps good for companies). There is P4Proxy, but that is readonly. Remote users on the other side of the world don't have the best experience.

I could list many other things. SCM has grown significantly since 1999, P4 hasn't.

Re:Perforce (1)

FranTaylor (164577) | about 5 years ago | (#29194955)

"getting stale."

How has the task of revision control changed over time to warrant adding new features? Did it ever occur to you that Perforce is a Stable product and many of us enjoy working with it just as it is?

Re:Perforce (2, Interesting)

hterag (39672) | about 5 years ago | (#29196181)

P4 is fast but don't be mistaken it too has some reasonable failings

is performance/reliability is terrible over a WAN
lacks an integrated secure communicaiton system
no disconnected operation
no archive/shelving operations

Re:Perforce (0)

Anonymous Coward | about 5 years ago | (#29194513)

Out of every single SCM platform I have worked with, both personally and professionally, I found Perforce to be the least logical and most difficult to use. With the possible exception of Visual SourceSafe.

Re:Perforce (1)

AuMatar (183847) | about 5 years ago | (#29195037)

TO say that you must never have used Clear Case.

Least logical? (1)

FranTaylor (164577) | about 5 years ago | (#29195143)

How is "less logical" to function robustly under a load of hundreds of developers checking in code while build jobs are simultaneously checking out code? How "less logical" is it for a single server to be able to hold the entire code reserve of a large software company and serve it to all its users? There is no other product that will function as well as Perforce under such a load.

Re:Least logical? (0)

Anonymous Coward | about 5 years ago | (#29195215)

Everything you just listed has nothing to do with what I said. I said it was the least logical: the command line tool was illogical. The documentation was illogical. The terminology used by P4 is unlike anybody else. The log information presented by the command line tool was spotty and difficult to read at best. Perforce was illogical. At least to me, and I've used enough SCM platforms to know. Hell I can even make sense of the VSS branch semantics.

Re:Perforce (0)

Anonymous Coward | about 5 years ago | (#29194771)

I find Perforce difficult to use when it comes to creating small personal branches, but maybe I'm just inexperienced.

Re:Perforce (0)

Anonymous Coward | about 5 years ago | (#29195351)

Did they *ever* fix the symlink bug? Where you change a symlink, commit your change, check out the repository somewhere else and it *SETS THE SYMLINK TO THE OLD TARGET*!!!!????

That stupid thing got me formally censured for editing core configuration files, when it was pointing to my local branch but the checkout pointed it back to the core configuration files and I accidentally edited that. Nasty, nasty, nasty, nasty bug.

No revision control! (0)

Anonymous Coward | about 5 years ago | (#29194433)

No revision control can help add to your job security! :-p

Re:No revision control! (1)

CarpetShark (865376) | about 5 years ago | (#29194677)

No revision control can help add to your job security! :-p

Indeed. There's nothing like a month of inspired coding that fucks up the whole codebase before you realise it won't work, to keep you in a job.

Git and Mercurial? (4, Insightful)

capnchicken (664317) | about 5 years ago | (#29194463)

Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.

Re:Git and Mercurial? (5, Interesting)

Vanders (110092) | about 5 years ago | (#29194547)

I share your scepticism. Given the vast numbers of CVS repositories that exist and the ease with which you can transition to Subversion, I don't think it's popularity is going to wane any time soon. It also has some of the widest range of plugins for IDEs such as Visual Studio and Eclipse and the largest number of tools and clients, which make it a popular choice for a lot of new projects. Outside of Linux development Git is almost unheard of, but may gain popularity and although I've worked with Mercurial professionally I've yet to see it used anywhere for Open Source development, yet.

Re:Git and Mercurial? (0)

Anonymous Coward | about 5 years ago | (#29194681)

Outside of Linux development Git is almost unheard of, but may gain popularity

If you meant outside linux kernel development, you'd be wrong. A lot of projects have moved to git (GNOME, Moblin, xorg come to mind right away).

Re:Git and Mercurial? (1)

Vanders (110092) | about 5 years ago | (#29194745)

Yes, and Glibc moved recently and I assume more GNU projects will follow suit. However that's still a very small subset of Open Source projects.

Re:Git and Mercurial? (1)

JohnFluxx (413620) | about 5 years ago | (#29194887)

KDE is also currently moving to git. Currently Amarok and a few other KDE apps have switched first, to iron out any bugs.

Re:Git and Mercurial? (0)

Anonymous Coward | about 5 years ago | (#29194549)

For new projects, sure. They're vastly better than SVN in nearly every way imaginable. Unless you have some kind of massive SVN-dependent infrastructure *and* a ton of developers who are too stubborn or clueless to learn anything new, it would be crazy not to use Mercurial is a new project. It really helps change your workflow to something that makes coding a joy again, even if you're working in C++.

Re:Git and Mercurial? (3, Insightful)

Vanders (110092) | about 5 years ago | (#29194579)

it would be crazy not to use Mercurial is a new project

Mercurial is a distributed system, Subversion is centralised. They suit almost totally different workflows and teams. If you're a large group of Open Source developers in different countries and timezones Mercurial may suit you. If you're a small group of developers in the same office doing rapid development, Subversion may be better for you.

Re:Git and Mercurial? (2, Insightful)

JohnFluxx (413620) | about 5 years ago | (#29194671)

This can only be said by someone that hasn't used a distributed system.

Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.

Re:Git and Mercurial? (1, Insightful)

Anonymous Coward | about 5 years ago | (#29194717)

This can only be said by someone that hasn't used a distributed system.

I used Mercurial (& CVS) in my last job. Prior to that I was a Build Engineer & SCM administrator, using Subversion, CVS, VSS (Oh God) and a little Perforce.

Distributed systems like Mercurial are nice but they do not suit every development style. A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution. That doesn't even begin to cover things like the vast number of SVN plugins & clients for all sorts of IDEs and editors, effective backups, build management and possibly other minor issues depending on the team and the organisation.

Re:Git and Mercurial? (1)

JohnFluxx (413620) | about 5 years ago | (#29194789)

> A large scale commercial development team, for example, is much more likely to be structured in a way where Subversion would be a better solution.

I work in a large scale commercial development team and we use git. I still see no possible advantage of SVN over git from that structural point of view.

The plugins and clients for git will grow rapidly I'm sure.

The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.

Re:Git and Mercurial? (1)

Vanders (110092) | about 5 years ago | (#29194857)

I work in a large scale commercial development team and we use git.

Yes and I've worked in a large scale commercial development team and they used Mercurial. I'm not saying it can't be done, just that it doesn't suit everyone. I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management. Sometimes you don't get to make that call.

The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.

Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime. Again, I am not suggesting this can not be done, just that it has to be considered if you use a tool such as Mercurial.

Re:Git and Mercurial? (2)

JohnFluxx (413620) | about 5 years ago | (#29195007)

I've worked in commercial development teams where a distributed system would not have worked, at all, due to external constraints and processes imposed by management.

What sort of constraints? Just wondering.

The backup thing though has to be joke. Every single person that checks out the code is making a complete backup.

Every single developer has a local repository with local changes. If you're doing things right your developers are only pushing their changesets to the central repository every couple of days. You have to ensure those local changes are backed up in the meantime.

Or you simply don't bother. Losing one developers 'couple of days' work usually isn't a big concern. It's common for svn users to also have several days worth of work uncommitted.

Although with git you can get people to trivially push as a branch to the server (git push origin master:mybranch) which is much more difficult in SVN.

Re:Git and Mercurial? (1)

Vanders (110092) | about 5 years ago | (#29195117)

What sort of constraints? Just wondering.

One particular instance was security. They had split the project down into modules and wanted to restrict certain developers to certain modules (for various reasons which I didn't bother to question). Using a centralised system (SVN) made this fairly simple. Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.

I've also worked with teams where the managers wanted to see a single commit log in real time, managers who wanted to ensure developers checked in changes with an attached change control or bug tracking number and reject commits that did not match the criteria and all sorts of other stuff that only a manager could want. All stuff that ranges from "tricky" to "impossible" with most (all?) distributed systems due their nature but where easy enough to do with Subversion & could have been done with most other centralised systems.

I've liked working with distributed SCMs. I really like Mercurial. It isn't a silver bullet and it won't suit everyone. Sorry, but it's true.

Re:Git and Mercurial? (2, Interesting)

JohnFluxx (413620) | about 5 years ago | (#29195245)

> Using a distributed system such as Mercurial would have made this near impossible as there would be no way to stop someone cloning a developers local repository.

How is that different from just copying a developers svn copy? You wouldn't get the history, but you would get the code...

The other things are also possible. See git pre-commit hooks.

Re:Git and Mercurial? (1)

ckaminski (82854) | about 5 years ago | (#29195781)

<quote>It's common for svn users to also have several days worth of work uncommitted.</quote>

I don't know what sort of developer you are, but I commit to my local branch several times a day, simply because I know I fuck up a lot and might overwrite changes I made earlier or rewrite code that I'm modifying to find a bug in.

It's not uncommon for me to check in once an hour.

My changes can get put onto the server many times a day with subversion. Not so much with git, SVK, or Hg.

Re:Git and Mercurial? (1)

EvanED (569694) | about 5 years ago | (#29194825)

I almost totally second this.

The workflow with something like Git or Mercurial is very helpful even if you have a strongly centralized team. You can work on your project on the bus (or at home after you move into a new apartment and don't have internet access for a couple weeks, not this this happened a couple weeks ago to me) without worrying about hoarding changes that you can't commit yet and branching (again useful even if you only have one person) is far less painful than it is with svn. (To be fair I haven't had a chance to try the merge tracking features in 1.5. But at least pre-1.5, the difference was night-and-day.)

Now, that said, I know Subversion really well, and when I tried Git last there were a couple times I managed to get my working directory into semi-corrupt states that I couldn't figure out how to solve. I also think that going from no version control to CVS is a larger step than going from CVS to SVN, and that going from CVS to Subversion is a larger step than going from Subversion to Git, so I am finding it hard to actually use it myself. Besides, the main project I'm working on now has me stuck on CVS ("Crappy Versioning System").

Re:Git and Mercurial? (1)

JohnFluxx (413620) | about 5 years ago | (#29194957)

It's pretty much impossible to corrupt git, since every commit is SHA1 checked.

Run: git reflog

and it shows you every change that you made (commits, merges etc). You can then roll back to any point in time. Simply find the magic 6 letter SHA that git reflog gives you for which ever commit you want to go to, then:

git reset --hard SHA

or alternatively:

git reset --hard HEAD@6

to mean to rollback as it was 6 changes ago (it makes more sense when you see the output from git reflog)

(--hard will delete any uncommitted changes)

You can even undo your undos etc.

Corrupt working directories (1)

coryking (104614) | about 5 years ago | (#29195841)

I haven't fooled around much with Git, but from what I understand, unlike subversion it doesn't pollute the working copy with a bunch of trash. It is trivial to corrupt a subversion working copy and I find it one of the least stable aspects of an otherwise extremely stable system.

I understand the subversion dudes are working on moving their trash out of the working copy. Hopefully they can get that done soon! The several times some brain-dead script accidentally ran over my working directory and messed it up left me just short of dumping subversion right then and there.

Re:Git and Mercurial? (2, Insightful)

Rob the Bold (788862) | about 5 years ago | (#29194879)

This can only be said by someone that hasn't used a distributed system.

Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.

Wouldn't distributed and centralized version control degenerate to the same thing in the case of a single user? I've never used a distributed system, what difference would there be in that case?

Re:Git and Mercurial? (1)

JohnFluxx (413620) | about 5 years ago | (#29195029)

Say you offer the repository to the world, so that your users can get your latest work to try it out.

And now you want to do a large refactoring of your code. You could do that as a series of commits locally, test it etc, and then push to the server in one go. Rather than pushing the changes incrementally and leaving the system in a broken state in the mean time.

Re:Git and Mercurial? (3, Insightful)

RiotingPacifist (1228016) | about 5 years ago | (#29195213)

you can do that with either centralised or distributed systems, i fail to see your point.

Re:Git and Mercurial? (1)

css-hack (1038154) | about 5 years ago | (#29195527)

With a distributed system, you can still use multiple commits, so that your revision history is readable, and so that you have the advantage of version control when making your changes (ie, rolling back changes, tracking features in small bunches, etc).

Then you push all at once to the server, and all the other developers/users can see the individual commits, and make sense of them.

Re:Git and Mercurial? (0)

Anonymous Coward | about 5 years ago | (#29195877)

I can give my developers their own branch in the svn repository for them to do the same thing on. The differences are;

a) I (and the other devs) get to see their commit messages along the way so if they are going way off-piste then they can be reined in sooner.
b) I can totally control the final merge and apply QA practices to it.

What it boils down to is that a distributed system allows a developer to go hide in a cave for a while whilst under the illusion that stuff is safely checked in. It's not. If he got hit by a bus then his work in progress could be anywhere for all I know. Maybe that works for volunteer projects but for the enterprise that doesn't fly.

The reality is that accepting multiple parallel streams of code from different people is going to result in conflicts that need to be managed. It is better to discover, manage and resolve those conflicts as early as possible in the release cycle. That is true whether you are tumbling down the waterfall or rolling in agility. The quality improves, as does the release predictability.

A revision control system that promotes deferring conflict discovery and resolution promotes late bugfixes and late testing, which invariably lead to late releases and poor quality.

Re:Git and Mercurial? (0)

Anonymous Coward | about 5 years ago | (#29196311)

Last I checked, branches worked fine for that.

Re:Git and Mercurial? (2, Informative)

Wonko the Sane (25252) | about 5 years ago | (#29195291)

Even if you are the only coder, a distributed system is still better since you're going to have your version, and the version on the server, and you want to be able to play about with your local version before pushing to the server. That's the sort of thing that git/mercurial are excellent at.

I'm not even a coder but I already love git for getting the kernel sources. For years I have been downloading incremental patches from kernel.org but now I can update my tree with a single command. Just this weekend I installed git and cloned the kernel tree. Then I added the nouveau tree as a remote so I can try out KMS for my nvidia video cards. When I want to update my tree I can use just three commands:

git remote update
git merge origin/master
git merge nouveau/master

What's there not to like?

Re:Git and Mercurial? (1)

pescadero (1074454) | about 5 years ago | (#29194759)

You can have a centralized-server workflow when using a distributed tool. All you have to do is set up an extra server and say "Hey, this is the central server now".

Subversion has some advantages but that's not one of them.

Re:Git and Mercurial? (3, Informative)

Vanders (110092) | about 5 years ago | (#29194823)

All you have to do is set up an extra server and say "Hey, this is the central server now".

Yeah. I know. In fact I did just that at my last job when we implemented Mercurial. The problem is training developers to push their local changeset to the central repository and from stopping developers pulling from someone else and not the central repository. There was a least one incident a week where a conflict arose due to developers doing things like that which led to divergent codebases which required significant effort on behalf of one of the developers to merge and fix conflicts. I have no doubt these problems could have been fixed given time, but it was an uphill battle.

Re:Git and Mercurial? (1, Insightful)

Anonymous Coward | about 5 years ago | (#29195645)

That's like saying C is a bad language because it allows you to use both underscore_names and CamelCaseNames in the same program. If your developers don't follow your development policies and problems result then it's their fault and not the fault of the tools.

Re:Git and Mercurial? (1)

OrangeTide (124937) | about 5 years ago | (#29194983)

distribute systems have advantages for developers in the same office. Branches are cheap and easy to merge in distributed systems. Keeping a branch in subversion so you can backup your code everynight tends to blow up in your face if you have a rapidly changing trunk you wish to track. It adds about 10 to 60 minutes of extra work every time I want to merge recent changes back into my private branch. I also need to share with two other developers, so just waiting to commit is not a viable option either. They would like to be able to check out my tree and try it with theirs. Merging quickly becomes a horrible nightmare on subversion, as far as I can tell it was not intended to be used this way. I believe this is because subversion is centered around merging changes and contents of a branch(which is just a directory in svn).

On a distributed system you can merge histories together instead of trying to merge changes. They can intermesh like a zipper and end up just fine and often require no further interaction beyond initiation the merge. Obviously the SVM tools can't just magically make changes to the source code and guarentee that it will work. But what it can do is determine reliably that two identical changes pulled from different places are really the same change and deserve the same check-in comments and meta information.

It's hard to describe, but there is a lot of powerful patching and merging you can do in a distributed environment. And it lets small groups of developers cooperate on bits of overlapping changes quickly. You can merge in svn, but I argue that it is more work. (yet I offer no concrete proof, sorry)

Re:Git and Mercurial? (1)

palegray.net (1195047) | about 5 years ago | (#29195579)

You know, I used to think the way you do about this. Then I tried Git, and I wouldn't go back to anything else. I use it along with another employee to manage a documentation repository, and it's worked wonderfully. Decentralization has been awesome.

Re:Git and Mercurial? (1)

forkazoo (138186) | about 5 years ago | (#29194679)

Git and Mercurial are more popular than Subversion? That's the big news to me, with all snarkyness aside. I best be getting out of my bubble.

No shit. Most of my conversations about revision control systems involve whether or not there is any real reason to move from CVS to Subversion. I've used SVN at each of the last few places I've worked, and in my private life, everybody seems to use SVN.

Git seems to bewilder most people I know. I think part of it may be that most of the repositories I deal with are general purpose, and contain some code. If I were dealing with "real" single-project development repositories, I suppose my experiences might be different. But, my personal SVN repository contains more non-code than actual software by a very wide margin. For many things, a centralized model with a definite "this is the most current version of this file" is more useful than everybody having their own version of a file with an intention to merge parts together.

Re:Git and Mercurial? (1, Informative)

Antique Geekmeister (740220) | about 5 years ago | (#29195385)

Please do. For many corporate purposes Subversion is opular, but its truly awful security models (storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted, and refusal to publish workable configuraitons for purely anonymous access), coupled with its designers absolute refusal to support deleting contents from the repository (even if they're accidentally stored DVD images or copyrighted code) leads to a very harsh conflict between the idea of "source control deletes nothing, ever" and the idea of "throwing useless things away makes cleaner code".

I've come to profoundly hate Subversion for just these reasons, although I do administer it locally for certain projects.

Re:Git and Mercurial? (4, Insightful)

ckaminski (82854) | about 5 years ago | (#29196119)

<quote>coupled with its designers absolute refusal to support deleting contents from the repository</quote>

I don't necessarily disagree with you, but in places I've worked, if we removed code in such a fashion and an audit found out about it, we'd get pummeled. Especially if it was discovered after a public release. It's one thing to ship code copyrighted by someone else, it's something completely different to go about covering up the fact.

So I'm torn on this "feature."

Re:Git and Mercurial? (1)

walshy007 (906710) | about 5 years ago | (#29195583)

Git and Mercurial are more popular than Subversion? That's the big news to me,

For more recent projects, hell yes, subversion still has the larger installed base at the moment, but the speed with which git is being adopted is scary.

After learning git myself though I can see why, it's just a superior system. Even when working with SVN repositories I now use git because of the better functionality.

Re:Git and Mercurial? (1)

HuckleCom (690630) | about 5 years ago | (#29196393)

You should get out of your bubble. Some very large open source projects user mercurial now - Mozilla and Xen to name a few - there's a budding community just like github called bitbucket for mercurial. Hell, Tovalds made git for kernel development....

Re:Git and Mercurial? (1)

HuckleCom (690630) | about 5 years ago | (#29196397)

Torvalds, and Mozilla meaning Mozilla products ... I'm off a beat today, gimme a break.

I'd suggest Git (-1, Redundant)

Facegarden (967477) | about 5 years ago | (#29194467)

But then, I've never used any of them, or any kind of versioning system, I'm just deliberately wasting your time.
-Taylor

Re:I'd suggest Git (2, Funny)

CarpetShark (865376) | about 5 years ago | (#29194725)

I'd suggest Git too. But what I really want to know is... why does it matter *which* our project chooses? Surely IDE devs and bugtracker teams could build a decent abstraction layer so that any DVCS would work just fine with them.

I think Pida just spun-off an abstraction layer at least. Hopefully people will get behind it and put an end to these silly DVCS wars once and for all.

Besides, everyone knows language wars are where it's at ;)

Your official guide to the Jigaboo presidency (-1, Flamebait)

Anonymous Coward | about 5 years ago | (#29194473)

Congratulations on your purchase of a brand new nigger! If handled properly, your apeman will give years of valuable, if reluctant, service.

INSTALLING YOUR NIGGER.
You should install your nigger differently according to whether you have purchased the field or house model. Field niggers work best in a serial configuration, i.e. chained together. Chain your nigger to another nigger immediately after unpacking it, and don't even think about taking that chain off, ever. Many niggers start singing as soon as you put a chain on them. This habit can usually be thrashed out of them if nipped in the bud. House niggers work best as standalone units, but should be hobbled or hamstrung to prevent attempts at escape. At this stage, your nigger can also be given a name. Most owners use the same names over and over, since niggers become confused by too much data. Rufus, Rastus, Remus, Toby, Carslisle, Carlton, Hey-You!-Yes-you!, Yeller, Blackstar, and Sambo are all effective names for your new buck nigger. If your nigger is a ho, it should be called Latrelle, L'Tanya, or Jemima. Some owners call their nigger hoes Latrine for a joke. Pearl, Blossom, and Ivory are also righteous names for nigger hoes. These names go straight over your nigger's head, by the way.

CONFIGURING YOUR NIGGER
Owing to a design error, your nigger comes equipped with a tongue and vocal chords. Most niggers can master only a few basic human phrases with this apparatus - "muh dick" being the most popular. However, others make barking, yelping, yapping noises and appear to be in some pain, so you should probably call a vet and have him remove your nigger's tongue. Once de-tongued your nigger will be a lot happier - at least, you won't hear it complaining anywhere near as much. Niggers have nothing interesting to say, anyway. Many owners also castrate their niggers for health reasons (yours, mine, and that of women, not the nigger's). This is strongly recommended, and frankly, it's a mystery why this is not done on the boat

HOUSING YOUR NIGGER.
Your nigger can be accommodated in cages with stout iron bars. Make sure, however, that the bars are wide enough to push pieces of nigger food through. The rule of thumb is, four niggers per square yard of cage. So a fifteen foot by thirty foot nigger cage can accommodate two hundred niggers. You can site a nigger cage anywhere, even on soft ground. Don't worry about your nigger fashioning makeshift shovels out of odd pieces of wood and digging an escape tunnel under the bars of the cage. Niggers never invented the shovel before and they're not about to now. In any case, your nigger is certainly too lazy to attempt escape. As long as the free food holds out, your nigger is living better than it did in Africa, so it will stay put. Buck niggers and hoe niggers can be safely accommodated in the same cage, as bucks never attempt sex with black hoes.

FEEDING YOUR NIGGER.
Your Nigger likes fried chicken, corn bread, and watermelon. You should therefore give it none of these things because its lazy ass almost certainly doesn't deserve it. Instead, feed it on porridge with salt, and creek water. Your nigger will supplement its diet with whatever it finds in the fields, other niggers, etc. Experienced nigger owners sometimes push watermelon slices through the bars of the nigger cage at the end of the day as a treat, but only if all niggers have worked well and nothing has been stolen that day. Mike of the Old Ranch Plantation reports that this last one is a killer, since all niggers steal something almost every single day of their lives. He reports he doesn't have to spend much on free watermelon for his niggers as a result. You should never allow your nigger meal breaks while at work, since if it stops work for more than ten minutes it will need to be retrained. You would be surprised how long it takes to teach a nigger to pick cotton. You really would. Coffee beans? Don't ask. You have no idea.

MAKING YOUR NIGGER WORK.
Niggers are very, very averse to work of any kind. The nigger's most prominent anatomical feature, after all, its oversized buttocks, which have evolved to make it more comfortable for your nigger to sit around all day doing nothing for its entire life. Niggers are often good runners, too, to enable them to sprint quickly in the opposite direction if they see work heading their way. The solution to this is to *dupe* your nigger into working. After installation, encourage it towards the cotton field with blows of a wooden club, fence post, baseball bat, etc., and then tell it that all that cotton belongs to a white man, who won't be back until tomorrow. Your nigger will then frantically compete with the other field niggers to steal as much of that cotton as it can before the white man returns. At the end of the day, return your nigger to its cage and laugh at its stupidity, then repeat the same trick every day indefinitely. Your nigger comes equipped with the standard nigger IQ of 75 and a memory to match, so it will forget this trick overnight. Niggers can start work at around 5am. You should then return to bed and come back at around 10am. Your niggers can then work through until around 10pm or whenever the light fades.

ENTERTAINING YOUR NIGGER.
Your nigger enjoys play, like most animals, so you should play with it regularly. A happy smiling nigger works best. Games niggers enjoy include: 1) A good thrashing: every few days, take your nigger's pants down, hang it up by its heels, and have some of your other niggers thrash it with a club or whip. Your nigger will signal its intense enjoyment by shrieking and sobbing. 2) Lynch the nigger: niggers are cheap and there are millions more where yours came from. So every now and then, push the boat out a bit and lynch a nigger.

Lynchings are best done with a rope over the branch of a tree, and niggers just love to be lynched. It makes them feel special. Make your other niggers watch. They'll be so grateful, they'll work harder for a day or two (and then you can lynch another one). 3) Nigger dragging: Tie your nigger by one wrist to the tow bar on the back of suitable vehicle, then drive away at approximately 50mph. Your nigger's shrieks of enjoyment will be heard for miles. It will shriek until it falls apart. To prolong the fun for the nigger, do *NOT* drag him by his feet, as his head comes off too soon. This is painless for the nigger, but spoils the fun. Always wear a seatbelt and never exceed the speed limit. 4) Playing on the PNL: a variation on (2), except you can lynch your nigger out in the fields, thus saving work time. Niggers enjoy this game best if the PNL is operated by a man in a tall white hood. 5) Hunt the nigger: a variation of Hunt the Slipper, but played outdoors, with Dobermans. WARNING: do not let your Dobermans bite a nigger, as they are highly toxic.

DISPOSAL OF DEAD NIGGERS.
Niggers die on average at around 40, which some might say is 40 years too late, but there you go. Most people prefer their niggers dead, in fact. When yours dies, report the license number of the car that did the drive-by shooting of your nigger. The police will collect the nigger and dispose of it for you.

COMMON PROBLEMS WITH NIGGERS - MY NIGGER IS VERY AGGRESIVE
Have it put down, for god's sake. Who needs an uppity nigger? What are we, short of niggers or something?

MY NIGGER KEEPS RAPING WHITE WOMEN
They all do this. Shorten your nigger's chain so it can't reach any white women, and arm heavily any white women who might go near it.

WILL MY NIGGER ATTACK ME?
Not unless it outnumbers you 20 to 1, and even then, it's not likely. If niggers successfully overthrew their owners, they'd have to sort out their own food. This is probably why nigger uprisings were nonexistent (until some fool gave them rights).

MY NIGGER BITCHES ABOUT ITS "RIGHTS" AND "RACISM".
Yeah, well, it would. Tell it to shut the fuck up.

MY NIGGER'S HIDE IS A FUNNY COLOR. - WHAT IS THE CORRECT SHADE FOR A NIGGER?
A nigger's skin is actually more or less transparent. That brown color you can see is the shit your nigger is full of. This is why some models of nigger are sold as "The Shitskin".

MY NIGGER ACTS LIKE A NIGGER, BUT IS WHITE.
What you have there is a "wigger". Rough crowd. WOW!

IS THAT LIKE AN ALBINO? ARE THEY RARE?
They're as common as dog shit and about as valuable. In fact, one of them was President between 1992 and 2000. Put your wigger in a cage with a few hundred genuine niggers and you'll soon find it stops acting like a nigger. However, leave it in the cage and let the niggers dispose of it. The best thing for any wigger is a dose of TNB.

MY NIGGER SMELLS REALLY BAD
And you were expecting what?

SHOULD I STORE MY DEAD NIGGER?
When you came in here, did you see a sign that said "Dead nigger storage"? .That's because there ain't no goddamn sign.

Many choices, not mentioned here. (1, Interesting)

Anonymous Coward | about 5 years ago | (#29194497)

There's a brief mention of perforce (and then nothing after it). There's mention of CVS but it's dismissed [rightly so!] as old. This is JUST about svn, git and hg. No bzr, vss, darcs, arch, monotone, bitkeeper, clearcase, or visual studio team server. Now, maybe that's a good thing, maybe not, but the summary made me think they were going to deal with a range of revision control systems. They picked three. Oh well. :)

Re:Many choices, not mentioned here. (1)

kabloom (755503) | about 5 years ago | (#29194617)

They discuss darcs, but it's too esoteric for them to understand, so they don't discuss it too much. And they don't really go into differences between git and hg (if there are any).

Complex complexity (-1, Flamebait)

pz (113803) | about 5 years ago | (#29194511)

Sheesh, kdawson, could you please *try* to edit the summary copy a little, y'know, like an *editor* would? Three instances of complicate in one paragraph are two too many.

Question about subversion (1)

darkwing_bmf (178021) | about 5 years ago | (#29194569)

I have experience using rcs and it seemed good enough. Now I'm currently using subversion that someone else set up in the name of progress (not my decision). My problem is it's cluttering up my working directories with meta data, plus I run into consistency problems as I'm moving and merging code from temporary experimental folders and other teams folders that are not in the same repository. All of this was perfectly fine with rcs (I would just check out something, make whatever changes I needed to and check it back in), but subversion has problems with it (my hypothesis is other peoples' meta data is getting mixed up with my own, causing subversion to get confused). Does anyone else have this problem? Do all of the more recent systems share these issues? Am I just a clueless old coder confused by this new fangled technology?

Re:Question about subversion (1)

PotatoFarmer (1250696) | about 5 years ago | (#29194661)

It sounds like you're manually doing things that svn would rather handle itself - specifically, copy and merge. If you're doing those outside of the tool then you're going to confuse the hell out of the repository, which will in turn do its best to confuse the hell out of you :-)

Re:Question about subversion (1)

JohnFluxx (413620) | about 5 years ago | (#29194731)

Copying code between repository sounds like a bad idea to begin with - it means that you are losing the history of the files.

Also the temporary experimental folders should be done with branches. Unfortunately any centralised system sucks at doing branches, compared to git or mercurial.

Honestly, I think you should spend a few hours learning svn, and then get "git svn" and learn and use that.

Re:Question about subversion (1)

koiransuklaa (1502579) | about 5 years ago | (#29194817)

svn is a vast improvement over rcs and your use case sounds fairly common so I'd guess that you are doing something wrong.

As a sidenote, terms like 'experimental folders' and 'other teams folders' sound really bad: if your source control was sane you wouldn't need 'experimental folders'... What you really want is a tool that makes branches so cheap you can always create new ones... Any time you need to experiment, you just create a new branch on your local repo (and you can work on the main branch at the same time if need be). If you want others to see the branch just push it to a server as a branch. If the experiment is good, merging into main branch is easy. It may not sound like much but trust me, it's what version control should have always been.

Git does the above very nicely, I assume other 'last gen' version control systems do as well.

Re:Question about subversion (1)

Jack9 (11421) | about 5 years ago | (#29195409)

To get a "clean" copy of a directory, use the "Export" command from your local repo. Subversion is nice because it limits the number of commands that you can (and would need to) run but names them as strangely as any other Revision Control System. You do need to produce process for how branching is done.

Errata (5, Informative)

kabloom (755503) | about 5 years ago | (#29194607)

Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.

This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.

Re:Errata (1)

kabloom (755503) | about 5 years ago | (#29194687)

Additionally, he mentions (at the end of the article) that distributed systems have issues with old projects that have long histories as an area for further research. He doesn't discuss bzr, which has a SVN-like mode for working with repositories when an overly-large history size is a real issue. He also doesn't discuss git clone --depth which may help with such issues. The git documentation is overly conservative when describing what you can do with a depth-limited repository -- there are plenty of conditions under which you can push to remote branches and merge other peoples' work when your history goes back far enough -- the git developers just don't want to say what those are.

Maybe there's room for more research, but there are some solutions out there already that are worth discussing.

Re:Errata (1)

aurelianito (684162) | about 5 years ago | (#29194727)

Because Subversion offers working out of a shared branch as the path of least resistance, developers tend to do so blindly without understanding the risk they face. In fact, the risks are even subtler: suppose that Alice's changes do not textually conflict with Bob's; she will not be forced to check out Bob's changes before she commits, so she can commit her changes to the server unimpeded, resulting in a new tree state that no human has ever seen or tested.

This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.

The GP is correct, subversion only requires to update to the latest version to change the svn properties of a file or a directory. Normal commits can be made given that the files committed are not changed in the repository.

Re:Errata (3, Insightful)

forkazoo (138186) | about 5 years ago | (#29194763)

This statement is incorrect. Subversion requres you to update your working copy before committing whenever you have modified a file that has changed in the repository.

Yes and no. It is possible to only update/checkin at a certain level in the directory hierarchy, and miss a change to a header outside of the scope you are interested in. You have to be slightly beligerent to get into such a situation, but it can happen.

Re:Errata (1)

kabloom (755503) | about 5 years ago | (#29194949)

I guess I misunderstood. He must have been talking about the project standpoint where alice updates foo.c and bob updates bar.c. I don't think they have to see each other's changes to commit. But if they touch the same file, even though their changes don't textually conflict, then they do have to see each other's changes.

Re:Errata (1, Insightful)

Anonymous Coward | about 5 years ago | (#29194999)

Kind of. I think what the author was getting at is that if SVN doesn't detect a conflict, it will perform the merge and won't /force/ you to look at the file before committing. So, you can wind up with Bob calling function foo in his checkin while Alice deleted foo in hers, or more subtle errors.

It's still Alice's fault for not checking that SVN did the merge right, but that's not much consolation.

Re:Errata (1)

shawn(at)fsu (447153) | about 5 years ago | (#29195267)

You don't need consolation for this; you can always revert back to Bob's revision and have Alice go back and make sure her check in isn't overwriting Bob's code.

No they don't. (4, Informative)

SanityInAnarchy (655584) | about 5 years ago | (#29194623)

Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works.

Ok, yes, some tools do. For example, subversion supports trivial branching, but sucks at merging, so it encourages people to work on a common "trunk" branch. It also only supports a central server, so it "encourages" developing with a central server.

Git, on the other hand, "encourages" people to not put multi-gigabyte files in version control.

However, Git can be used to talk to an SVN repository. It can also talk to a central repository, or work purely via ssh between workstations, or with something like Gitjour, in a truly distributed fashion. Github is a strange and wonderful mutation of the two.

Perhaps, by making branches and merges so awesomely fast, Git "encourages" lots of little local branches, and keeping a neat patch history. But to sum it up:

SVN can handle large binary files and Windows better than Git, and is better integrated into IDEs.

Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

Re:No they don't. (4, Interesting)

russotto (537200) | about 5 years ago | (#29194803)

Git is better at everything else, ever. Seriously -- 99% of projects that are hosted on SVN would make more sense on Git.

When I first looked at git, it wasn't even clear how simple revision control tasks could be done, e.g. simply checking in a file, or reverting changes to it. Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things (and it's not just because it's distributed, as mercurial was much more straightforward). I assume that's changed as people aside from Linus actually use the thing, but it was very off-putting in the beginning.

Re:No they don't. (0)

Anonymous Coward | about 5 years ago | (#29195951)

In his Google Tech Talk on Git, LT describes initial versions as not being usable for anyone other than him...

I started using git about two months ago. It took a few days to get used to, but really wasn't that bad. And now, I couldn't got back to using anything else.

I'm strongly considering putting /etc, /bin, /usr, /sbin ... (major system directories) in git. Since I use apt, though, I need to figure out how to make the two play nicely together...

Re:No they don't. (4, Informative)

SanityInAnarchy (655584) | about 5 years ago | (#29196037)

It has changed, somewhat -- but mostly, I think there's just better documentation.

But, for example...

Looked like you had to deal with bizarre syntax and long hex numbers for the simplest things

That is pretty fundamental to the design -- it's a SHA1 hash. It's also not incredibly difficult -- cut and paste. When your SVN revisions hit four and five digits, they don't really have much more meaning than that hash, do they?

Generally, you learn to use relative terms, instead -- for example, HEAD^ to refer to the revision just behind HEAD.

mercurial was much more straightforward

I thought so, too...

I think I tried mercurial, and then bzr, and eventually settled on Git for three reasons:

  1. It's obscenely fast
  2. Everyone's doing it, which has a network effect (github)
  3. I can hold its data model comfortably in my head.

I should clarify that last part... Maybe some things are cryptic, and I'm sure I don't know all of the possible commands I could run -- but at a very basic level, I know exactly what's going on, just like I did in SVN.

Just for fun, here's the data model in a paragraph: There are commits. Each commit has a parent commit that it includes, except for merges, which have two parents. A branch is just a pointer to a commit.

That's it.

And knowing that, everything else starts to make sense... but it's more than I want to get into in a Slashdot post.

Re:No they don't. (0)

Anonymous Coward | about 5 years ago | (#29195105)

Subversion sucks at merging? I'd have to disagree. I'm an SCM for a CMM level 3 shop and we use Subversion. I run 7 concurrent (at peak times) branches and have no trouble merging. My repository is setup as a stable trunk with development occurring on the branches. There is an occasional conflict, but you can't always avoid that.

Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand and audit everything on the way

Re:No they don't. (2, Interesting)

SanityInAnarchy (655584) | about 5 years ago | (#29195863)

There is an occasional conflict, but you can't always avoid that.

Git avoids that a lot better than Subversion does. Yes, there's an "occasional" conflict, but much more rarely.

Call me a die hard, but I wouldn't trust Subversion's automatic merge feature. I do it all by hand

Yes, I've done that...

Doing it all by hand sucks -- it's a lot of manual effort to make sure you know exactly what you should be merging, and it still takes far longer to do that. Doing it with SVN's merge tracking sucks -- we had it to where it was taking half an hour, and could still fail.

I mean, I liked the model. I liked having a deep understanding of what it was doing.

But even by hand, even trying to disable all the merge tracking stuff, it still took minutes. And that's after doing the 'svn log' myself, trying to figure out exactly what should be merged...

In Git, I haven't found an operation that takes longer than seconds. Having five branches per developer is actually a perfectly sane and workable situation on Git -- having one branch per developer was a nightmare in SVN.

I doubt that anyone who's actually used a modern SCM can say with confidence that SVN merging doesn't suck. Half an hour for SVN vs one second for Git.

Version Control Systems all have one thing (1, Insightful)

MerlynEmrys67 (583469) | about 5 years ago | (#29194729)

in common - they all suck and suck equally

Well except for VSS, and Microsoft isn't even dumb enough to use that on their own projects.

This article was very limiting by only talking about a few small system, didn't even talk about "interesting" systems like ClearCase (Yes, you too must hire a Clear Case administrator to figure out this beast). I really liked the underlying technology where the VCS was treated as a filesystem driver and the current code that you were working on was handled as a set of operations on the file system.

Re:Version Control Systems all have one thing (1)

mandolin (7248) | about 5 years ago | (#29195959)

I used ClearCase at my previous job, and the mode of use you mentioned, while interesting (files could change in your source tree as others checked in code, I believe), was impractical for me. Building out of one of those directories was like building out of an NFS-mounted directory ... an order of magnitude slower, too slow to be usable.

ClearCase also supported the typical 'check your workspace ("view"?) out to a local place on your hard drive, rebase it occasionally, make your changes, and check it in' model, and that seemed to work fine.

And yes we had a full-time administrator for the system. Would've been suicide not to.

Re:Version Control Systems all have one thing (0)

Anonymous Coward | about 5 years ago | (#29196229)

Actually, no, they don't all suck.

"More Popular"? (2, Insightful)

adamkennedy (121032) | about 5 years ago | (#29194733)

> Today, leaders of teams are faced with a bewildering array of choices ranging from Subversion to the more popular Git and Mercurial.

I think you might be confusing Internet "buzz" with popularity.

Re:"More Popular"? (0)

Anonymous Coward | about 5 years ago | (#29195075)

What, that's crazy talk. Next you'll be suggesting that ruby on rails isn't as big java. Or that django isn't more important than C++.

TortoiseSVN (4, Insightful)

ImustDIE (689509) | about 5 years ago | (#29194807)

I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.

I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.

There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.

Re:TortoiseSVN (1)

Rob the Bold (788862) | about 5 years ago | (#29194947)

I am a bit jealous of some Git features, but the place I work -- and me for my personal projects -- use SVN for one big reason: TortoiseSVN. It is a great interface to version control and not everyone (probably the majority) who needs to contribute is a programmer, or has any idea about command line interfaces, ssh, branching, merging, etc.

I am aware of TortoiseGit, but it has not reached a stable release, so it is not up for consideration in a serious environment.

There are other things to keep in mind too; SVN is much more tailored to our repo structure than Git, so that's a big plus for SVN -- at least for us.

Tortoise is also cross-platform, for when that's important. And there's even TortoiseCVS, if that's your style.

Re:TortoiseSVN (0)

Anonymous Coward | about 5 years ago | (#29195833)

Tortoise is also cross-platform, for when that's important.

Ya, it runs on Windows and...er...Windows. That's cross-platform enough for anybody.

Re:TortoiseSVN (1)

N7DR (536428) | about 5 years ago | (#29196033)

Tortoise is also cross-platform, for when that's important.

I beg to differ.

From http://tortoisesvn.net/node/58 [tortoisesvn.net] :
TortoiseSVN is only available on Windows.

That page lists clients similar to tortoise for other OSes, but the real, genuine tortoiseSVN is Windows-only.

Re:TortoiseSVN (1)

IMightB (533307) | about 5 years ago | (#29195069)

I work for a company which switched from CVS->gnuarch->Mercurial (For the gnuarch, switch it was when we were small and the lone diva developer made the decision for us) (For the mercurial (Hg) switch we evaluated SVN, Git and a few others before settling on mercurial)

Hg has made merging a dream, and everything else is really easy. The biggest headache from the dev's was for a period of about two weeks where they had issues with the extra "Push" step.

I believe that Netbeans and Eclipse have Hg plugins and TortoiseHg is pretty nice there's even a tortoiseHg-nautalis plugin for you gnome users out there.

Overall, Hg is probably the best SCM that I've used.

Re:TortoiseSVN (0)

Anonymous Coward | about 5 years ago | (#29195617)

Overall, Hg is probably the best SCM that I've used.

doubleplus ungood newspeak

Some no-nothing cowoy coder hacked the wikipedia page for RCS http://en.wikipedia.org/wiki/Revision_control [wikipedia.org] to pretend "SCM" means "Software Configuration Management" and is therefore equivalent to revision-control.

The real SCM page http://en.wikipedia.org/wiki/Software_Configuration_Management [wikipedia.org] quite properly notes that SCM "is not to be confused with revision control".

Re:TortoiseSVN (1)

walshy007 (906710) | about 5 years ago | (#29195727)

even if your company uses a central SVN repo, you can still use git yourself, 'man git-svn' it allows you basically all of the advantages of git without any svn users even knowing that you're using it.

When you get used to the workflow you'll wonder how people ever used svn.

rawr (0)

Anonymous Coward | about 5 years ago | (#29194861)

I have found it exceptionally difficult to explain to people why revision control systems are useful. I am not talking to computer science people (sadly). For some reason people don't seem to want to spend the five minutes running through a common git tutorial. What am I doing wrong? No, powerpoint is *not* the correct medium to teach you how to use git. Grr.

Sincerely, an angry programmer.

Talk to a lawyer (1)

FranTaylor (164577) | about 5 years ago | (#29194931)

They understand revision control. Documents are to lawyers what code is to software developers.

Re:rawr (1)

Rob the Bold (788862) | about 5 years ago | (#29194995)

I have found it exceptionally difficult to explain to people why revision control systems are useful. I am not talking to computer science people (sadly). For some reason people don't seem to want to spend the five minutes running through a common git tutorial. What am I doing wrong? No, powerpoint is *not* the correct medium to teach you how to use git. Grr.

Sincerely, an angry programmer.

There's nothing you can do but the AA Serenity Prayer at this point.

Bazaar (1)

ggpauly (263626) | about 5 years ago | (#29195051)

We use Bazaar at ringdevelopment.com. Works fine for us, seems less labor intensive than svn.

Source Control Shingle (1)

acon1modm (1009947) | about 5 years ago | (#29195133)

Simple feature set, but none of us have ever clobbered anyone else's changes.

how about the tps report system for each change (1)

Joe The Dragon (967727) | about 5 years ago | (#29195463)

how about the tps report system for each change the PHB makes a big fuss about it when you don't do them and gets on your ass when you take the time to do them and your other work fail behind when you take the time to do them.

Git (0)

Anonymous Coward | about 5 years ago | (#29195487)

The more popular Git? since when

Re:Git (0)

Anonymous Coward | about 5 years ago | (#29196029)

The slashdot servers are colocated in an alternatve universe where every computer runs linux, every phone is an android, ogg is used for all audio/video, and git is the most popular vcs.

No mention of ClearCase? (3, Informative)

gillbates (106458) | about 5 years ago | (#29195587)

What I find interesting is there's no mention of ClearCase. Maybe the author is unaware of it, or considers it obsolete? Then again, the author didn't seem that experienced with the debacles into which one can get with revision control SW. The example he posits is the least of the problems which can crop up.

I've used both ClearCase and CVS. First, CVS:

  1. I instinctively save files. And this is a bad thing to do with CVS; when I do a commit, my otherwise unchanged file can overwrite another engineer's more recent changes because I happened to save the file at a later date than him. The interesting thing is that this is not immediately apparent to either of us until we check out a fresh copy of the repository and he notices his changes are gone. And then I'm listed as the last modifier, and he comes to me...
  2. You can't (or shouldn't) copy one directory to another within a source tree. Nor should you do it between repositories. CVS will commit your changes to the copied directory back to the original repository, unless you delete all of the CVS folders. This little quirk cost a few of my colleagues a few hours of debugging to figure out why their changes kept disappearing...
  3. CVS does not (or did not when I used it) enforce strict version control protocol. I can commit an entire repository back to mainline even if I have outdated files. Even if others have made more recent updates. I didn't know this was happening for a good few months of use...

Now for ClearCase

  1. ClearCase can manage extraordinarily large codebases spread across several geographical locations.
  2. It can be integrated with version control and bug tracking databases.
  3. It allows two or more developers to work on the same file at the same time, with the last one to commit having to perform a manual merge *only when there are conflicts*. Most of the time, it gets the merges right.
  4. With proper tagging procedures, I can always reproduce the last build bit-exact. No matter how badly an engineer subsequently mangles the codebase, I can always build from the last tag. My impending release can't be sabotaged by another developer committing code-breaking-but-it-compiles-on-my-machine-oh-silly-me-I-forgot-the-headers kind of changes.
  5. It does have problems with cache-coherency. Modifying files on machines other than the build machine may end up with stale files being linked...
  6. It has dynamic views, which don't require a full copy of the source tree on the local machine. There are some big advantages to this, among them being not having to worry so much about the theft of a developer's laptop, and using the server's storage pool for building, rather than the local hard disk. From a developer perspective, it is nice not to have to wait an hour or so for the repository download should I need to make a change to an older codebase. I can work on multiple versions of the same code base at the same time, without having to maintain a separate local copy of the entire tree for each of them.
  7. Managing ClearCase is an administrative position. Yes, it is exceedingly complex.
  8. Suppose I merge several bug fixes for a build. And later, one of those fixes needs to be backed out (didn't fix the problem, conflicts with other SW, etc...). I can do that with ClearCase rather easily, without having to reconstruct all of the interim versions between the two.
  9. I can apply the same bugfix to two different branches of a source tree without checking out and modifying both branches. That is, I can check the changes into one branch, and merge them into another branch (or just pick them up) without having to checkout the repository from the other branch.

Now, granted, a lot of FOSS products are not trying to be SEI level 5*. They don't have to demonstrate a repeatable process. The often don't incorporate bug fixes into older releases, or maintain several concurrent branches of the same codebase. It is also important to show which bug fixes went into a particular release; more importantly, to be able to demonstrate what changed in which source files for a given bug fix, even one several versions old.

So how to perforce, and git, and mercurial compare? Are they glossed over reinventions of CVS, or fundamentally more powerful systems?

*-Yes, I know there are bound to be exceptions to the rule. But, one of the most visible illustrations of this is the Linux kernel, where things broken in older kernels simply don't get fixed.

Re:No mention of ClearCase? (0)

Anonymous Coward | about 5 years ago | (#29195785)

errr, every single thing you said about CVS is false. What are you a IBM shill?

Re:No mention of ClearCase? (1)

William Ager (1157031) | about 5 years ago | (#29196387)

Essentially everyone who knows anything about modern version control considers CVS obsolete. Many of the things you discuss in your comment were considered, discussed, and resolved years ago, though different systems went about solving them in different ways.

SVN is essentially CVS with most of the annoying problems fixed, and several other advantages besides. Most other systems are completely different. There are even many people who consider any version control that isn't distributed to be obsolete.

It's rather difficult to describe such things here, however. I'd recommend looking into Darcs, Git, and Mercurial; they're all very different from CVS and ClearCase, and Git and Mercurial can do almost everything you describe and more (there are design decisions that prevent other things from being possible); some of the things you describe don't even make sense in their models. As the article notes, Darcs goes so far as to use a different model of changes.

It's quite probable that the author does consider ClearCase to be obsolete, yes.

Clearcase. (2, Insightful)

Ungrounded Lightning (62228) | about 5 years ago | (#29195633)

I've only tried a few revision control systems.

Of those I've tried, Clearcase is the hands-down winner function-wise, especially for the diverge-converge model of multi-programmer development.

Extremely lightweight branching. "View spec" - a little language to specify exactly what version of what you want: (Version x.y.z but override by the foobar feature development branch but override that by anything in /src/garble as of Tuesday at 3:15PM but override all with anything I've got checked out in MY development branch...). Integration into the filesystem so your tools "see" containing just what version of the sources you specified. A make variant that imports already-built objects that some OTHER developer made from the equivalent sources, rather than compiling them again, etc.

Downside: It's commercial and 'way pricey.

But if you're a commercial shop you should at least evaluate it. The functionality is fansastic.

(I hear some of the core functionality came from an open-sourced student project. I've often wondered why there isn't a FOSS clone of the important features - or if there is and I just missed it.)

Bazaar (0)

Anonymous Coward | about 5 years ago | (#29195765)

How can no one have mentioned Bazaar http://bazaar-vcs.org/ [bazaar-vcs.org] yet? For me, it's a great compromise between having my eyes and brain bleeding from being forced to use the atrocity that is git (or CVS come to think of it, which I'm still stuck with at work), and all the quirks and issues with Subversion.

It works the same on Linux and Windows , has a TortoiseBZR GUI for Windows, and is very flexible in just about all respects. Sure it's written in Python and is a tad slow. If your project is big and complex enough for that to matter, you already know that and are using git or whatever. For everyone else it's great.

Savana - transactional workspaces on top of SVN (3, Interesting)

SashaMan (263632) | about 5 years ago | (#29196377)

Friends of mine have open-sourced savana, http://savana.codehaus.org/ [codehaus.org] a thin layer on top of Subversion that makes it easy to do all work in private branches before promoting to the trunk. A common workflow is:

sav createuserbranch mybranch --calls svn copy under the covers to create user branch named mybranch ... normal checkins using svn commit go to YOUR private branch ... when you are ready to promote your changes back to the trunk:
sav sync -- pulls in any changes made to trunk since your private branch was created so you can test locally
sav promote -- merges your changes back into the trunk

The thing I like about this thin "workspace managing" layer on top of Subversion is that for the most part you can take advantage of existing tool support for subversion (like integrated IntelliJ Idea and Eclipse support), as all of the savana commands just call svn commands under the covers.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>