Making Sense of Revision-Control Systems

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."

Comments

Perforce

[saccade.com]

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

[ZeekWatson]

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

[Anonymous Coward]

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

[xmundt]

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

[Anonymous Coward]

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

Re:Perforce

[FranTaylor]

"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

[AuMatar]

TO say that you must never have used Clear Case.

Re:Perforce

[Anonymous Coward]

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.

Re:Perforce

[ZeekWatson]

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

[hterag]

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

[Terazilla]

Not to mention P4 absolutely trusts the server as to the state of your local repository. Get a few files overwritten locally somehow and good luck figuring out what's wrong when something starts acting weird a month down the road.

Re:Perforce

[Zero__Kelvin]

"How has the task of revision control changed over time to warrant adding new features?"

Dramatically ! Distributed revision control is fairly new, and taking over fast. I'm not sure if the summary is correct that git and mercurial (distributed SCM Tools) are now more popular than antiquated client/server SCM tools like CVS, Subversion, perforce, etc.. but it certainly should be true because the distributed paradigm is a major improvement. You should research this stuff. You'd be amazed at how much is "new" in Source Control/SCM.

Re:Perforce

[macsuibhne]

That's what 'p4 diff -se' is for. It basically asks the server 'have I got any local edits that you don't know about?'. (Also '-sa' and '-sd' for local adds/deletes.)

Re:Perforce

[Peaker]

We've recently migrated from Perforce to Git.

Git is much much better.

I recommend everyone to use modern DVCS tools, and not older centralized ones.

Re:Perforce

[godefroi]

A truck, huh? Do you just dump things on it?

Anyway, in all seriousness, there is a whole world of features that revision control tools should have. If there weren't, we'd all still be using RCS. P4 isn't the pinnacle of software design, and neither is any other revision control system that exists today.

Re:Perforce

[crotherm]

With all due respect to the many excellent coders who have contributed to this thread, IMHO the tools and methods discussed seem to be a rather free lance version of coding.

I have worked in areas of the computing worlds where coding is tightly controlled by humans and not software. Review boards, meetings, team efforts....

IMHO, relying of software to enforce proper coding practices is lazy. Communication is the key... Communication among coders who CAN communicate should be without question. Revision control software is not and should not be a mind reader.

And finally gvim >> emacs...

Re:Perforce

[macsuibhne]

Allow me to help you out here:

http://www.perforce.com/perforce/doc.current/user/relnotes.txt

No revision control!

[Anonymous Coward]

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

Re:No revision control!

[CarpetShark]

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?

[capnchicken]

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?

[Vanders]

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?

[Anonymous Coward]

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?

[Vanders]

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?

[JohnFluxx]

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?

[forkazoo]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[Vanders]

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?

[pescadero]

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?

[JohnFluxx]

> 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?

[Vanders]

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?

[EvanED]

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?

[Vanders]

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?

[Rob the Bold]

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?

[JohnFluxx]

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?

[JohnFluxx]

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.

Re:Git and Mercurial?

[OrangeTide]

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?

[JohnFluxx]

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?

[JohnFluxx]

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?

[Vanders]

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?

[RiotingPacifist]

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

Re:Git and Mercurial?

[JohnFluxx]

> 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?

[Wonko the Sane]

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?

[Antique Geekmeister]

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?

[css-hack]

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?

[palegray.net]

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?

[walshy007]

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?

[Anonymous Coward]

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?

[ckaminski]

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

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?

[Anonymous Coward]

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?

[ckaminski]

coupled with its designers absolute refusal to support deleting contents from the repository

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?

[Anonymous Coward]

Last I checked, branches worked fine for that.

Re:Git and Mercurial?

[HuckleCom]

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?

[HuckleCom]

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

Re:Git and Mercurial?

[hysterion]

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

But that's only a 'legacy' problem. Today, going from no version control straight to Git/Hg is much easier than even your first step -- and saves you from having to unlearn all that intermediate junk.

Re:Git and Mercurial?

[turbidostato]

"you want to be able to play about with your local version before pushing to the server"

Maybe your manager doesn't want you working with your local version and then your work being unaccountable. Maybe your manager preferes you working on a personal branch on the centrallized repo.

Re:Git and Mercurial?

[turbidostato]

"What sort of [managerial] constraints? Just wondering.
[...]
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."

*That* kind of managerial constraints. Losing 'couple of days' of development work *is* a concern; having several days worth of work uncommitted *is* a concern.

Re:Git and Mercurial?

[Anonymous Coward]

effective backups

You don't have a fucking clue _what_ you're talking about! DCVS creates a complete backup _every_ _goddamn_ _time_ someone checks out the code! You didn't use mercurial at your last job. You were fired because you couldn't use it.

Re:Git and Mercurial?

[warrax_666]

If you're doing things right your developers are only pushing their changesets to the central repository every couple of days.

With a DVCS the developer just has their own branch (which can be on a central server) and they can commit whenever they like and have everything backed up -- branch management is so easy with most DVCSes that this is a non-issue. Now, if the developer is disconnected for long periods at a time, then you might have a point... but in that case a centralized VCS is even worse. At least with a DVCS the developer can just tar up the working tree (including .git, .bzr or whatever) and email that to himself to have a backup.

Re:Git and Mercurial?

[stephanruby]

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.

I guess I must be living in my own bubble then. Not that subversion isn't the most dominant version control system out there, it still is I think, but recently I've been using github (which uses git) and google code (which uses Mercurial) most of the time -- and I can see why someone could mistakenly think that github and google code are the only thing there is (after all, who uses sourceforge/tigris anymore? I'm sure some people still do use those repos, but I certainly wouldn't start a new open source project on those -- now that I have github).

Re:Git and Mercurial?

[pthisis]

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.

git to CVS transformation and a server that servers git repos to CVS clients exist, too.

SVN is in a weird place: it's not exactly legacy. There are certainly new projects choosing it. But almost all of those know that it's an intermediate step that'll be out the door in a few years.

There's 1 major reason to choose SVN over git: better GUI clients. That could be pretty compelling in some shops (even as a long-term decision--there will be fine SVN to git transition tools available if and when you decide to make another switch), but you have to realize that you're getting yourself into a worse VC system and some long-term pain in exchange for some (non-trivial, to be sure) short term benefit.

Certainly it was a nice stepping stone, and even today there are some good reasons to pick it (especially for shops that have a lot of Windows development), but SVN has absolutely already waned a lot in popularity over the past few years. In 2005, it was the clear choice for most new projects; now, most places I work at are deciding between short-term client flexibility and short-term distributed VC, but they pretty much all know that in 4-5 years they'll be using a distributed VC system.

Re:Git and Mercurial?

[Lennie]

only pushing their changesets to the central repository every couple of days.

With a distributed system, you can push it to a central server to an own copy (each developer has it's own url to keep a backup) at any time, like the end of the day.

You can't do that with a centralized system.

Maybe it can even be used by others to pull from.

Re:Git and Mercurial?

[jb_nizet]

Subversion calls this a feature branch. You branch the trunk, which stays open to the public. You make regular commits to the branch, and when the large refactoring is done in the branch, you reintegrate the branch into the trunk. The trunk remains stable during the whole process.
How is it different with a distributed system?

Re:Git and Mercurial?

[TheThiefMaster]

We're talking about the single-user case here.

Re:Git and Mercurial?

[EvanED]

Sorry, I phrased what I meant poorly. What I really meant is that "going from no version control to CVS brings more benefits than going from CVS to SVN, and that going from CVS to SVN brings more benefits than going from SVN to Git."

This is also a YMMV... I'm also still talking about small centralized teams or even a single person. If you have larger teams things may change; if you have actually decentralized teams, then things almost certainly will change. However, I would say it's definitely true for me and the sorts of projects I'm working on.

Re:Git and Mercurial?

[orzetto]

[Subversion's] designers absolute refusal to support deleting contents from the repository [is bad]

That is one great feature of Subversion: absolutely no way to screw up stuff that was committed. Revision control is about keeping track of stuff, any model that allows a user to remove information from a repository is a disaster quietly waiting to happen; sorry you did not understand that.

If you absolutely need to remove something from a SVN repository, you can do that with svndumpfilter, meaning you have to ask the repository's administrator. That's a good safeguard against accidental deletions.

"throwing useless things away makes cleaner code"

For "cleaner code" you just need svn delete.

Re:Git and Mercurial?

[ToasterMonkey]

There's 1 major reason to choose SVN over git: better GUI clients.

I think SVN Apache/DAV integration is much more polished than git's. Things like VisualSVN give you out the box Active Directory integration, with a management interface to boot.

Re:Git and Mercurial?

[Anonymous Coward]

I guess that's possible. I work in GNOME/Moblin-related circles and haven't had to use SVN since January (and am thankful for it). About 70% of the code checkouts I have on my machine are git.

Re:Git and Mercurial?

[locofungus]

There are only a few use cases where single user distributed and centralized revision control systems differ.

1. You can carry a local repository on your laptop and commit. You do not then need to sync to the master repository before continuing work there. (Typically in a distributed system there is one repository that is given the status of master - this avoids issues where two teams might be syncing amongst themselves but both are blissfully unaware that there is any other work happening in the same area of code.)

2. You can work simultaneously on two separate checkouts and commit them without having to "promote" one of them to a branch.

IMO any RCS that doesn't allow you to commit your tested and working snapshot whenever you want is fundamentally broken. Distributed systems must support this by definition[1] and any non distributed system that supports this can trivially be made distributed.

[1] Some distributed systems require you to merge when you synchronize changes. IMO merging should be separate from synchronizing

Tim.

Re:Git and Mercurial?

[JohnFluxx]

If you want a policy that everything has to be in branches, then you can do that in git. In fact it's much easier in git than svn.

> 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.

With SVN, a developer can go hide in a cave for a while without ever committing stuff. What's the difference?

The part about committing as early as possible doesn't really make sense to me. If you have two group with large changes, then git allows those two groups to merge with each other, making it easy to catch problems _before_ merging with head.
That is something SVN just cannot do.

Re:Git and Mercurial?

[Anonymous Coward]

A distributed system doesn't need a server. That was my main reason for picking git over cvs or subversion.

Merging branches are said to be much better in distributed systems too. It has to be very good, you do that all the time in a distributed system. According to a certain Google talk about git, it's really bad in CVS and Subversion, but I never tried myself.

Re:Git and Mercurial?

[gbjbaanb]

Its not so much a refusal to support full deletion than a problem that the task is difficult - subversion was designed not to delete anything placed in the repository (except as a awkward admin task), and now everyone realises that it is desirable to do this occasionally, they're finding it'll be a hard job to do - so it gets put off until next the major version. Its been put off like this since v1.2 IIRC.

Google for svn obliterate for the full details, the svn docs has a spec for the work. If you want to work on it, feel free.

That said, there are issues where the dev team refuse certain patches that make a lot of sense to many - like implementing revision-number labels as tags instead of using branches, but its still not a hateful VCS even given these problems.

Re:Git and Mercurial?

[gbjbaanb]

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

The trouble with this is that you have to worry about your laptop crashing, being broken or stolen. Today, with a £30 usb wireless dongle, you can commit changes no matter where you are. The lack of internet access isn't a good enough reason to advocate a distributed VCS. They have plenty of other good aspects to them, but being able to easily hoard changes locally is more a disadvantage than anything.

Re:Git and Mercurial?

[Anonymous Coward]

And going from no souce control to git is easier than setting up a CVS server.

Git doesn't require a server. You can make one if you want to, but you don't need one.

Re:Git and Mercurial?

[Bacon Bits]

storing passwords silently in your local $HOME/.subversion/auth direcotory by default, unencrypted

Call me crazy, but exactly how is this insecure? It's the filesystem's job to provide security, hence the access for the directory is 700. Exactly what kind of scenario would an unauthorized person having access to your home folder not already be enough of a security breach so as not to matter? Even then, you can turn off password caching entirely if you want if you're really worried about it (store-passwords = no).

Even then, the FAQ claims that the system will use Keyring or KWallet if you've got them, too (and similar encryption features on Windows and OS X).

Re:Git and Mercurial?

[Anonymous Coward]

Then make that policy.

Even if you use a system that can't do anything else, there's still the option of not committing anything.

Re:Git and Mercurial?

[EsbenMoseHansen]

Actually, while ugly as sin, git gui is quite useful and intuitive. Works a charm for staging and managing branches, which are the 2 areas where I feel a GUI is most welcome.

Re:Git and Mercurial?

[Anonymous Coward]

The fact that it gets stored is what makes it insecure. There are a lot of systems where it is reasonable to do one quick commit, but not to let the password lie around for years (basically any university system falls in that category IMO, they are kept safe enough generally but still get hacked at least every other year).
Storing passwords without user consent is just an absolute no-go in my opinion, luckily chmod 000 ~/.subversion/auth works well enough (and is easier to remember than that configuration option that you never know if it will suddenly stop working e.g. because they renamed it or started to get a bit more full of themselves and finally removed it completely).

Re:Git and Mercurial?

[Vanders]

The local repository will have local commits which are not pushed to the central repository. Where is the backup of these commits?

Re:Git and Mercurial?

[Vanders]

I never said Mercurial or any DVCS was bad. I said it appeared to be more of an endemic problem to get developers to use it correctly than with a centralised VCS such as Subversion.

Re:Git and Mercurial?

[Antique Geekmeister]

It's on every backup tape. Anyone with access to your (potentially NFS shared or CIFS shared) home directory also has access to the plain-text files. You may as well tattoo it on your forehead, because every script kiddie in the world knows to go looking for these, and they've been silently stored on Subversion clients all over the world. (Subversion 1.6.x at least asks before storing them, but that's hardly enough.)

You may think your local system admin and backup manager, whether it is you, your son, your daughter, or your systems administrator at work, is perfectly trustworthy with that information. But Subversion has already made that decision for you. And no, they _should not_ have access to my passwords simply because they can access my machine.

Password caching is on _by default_ and is awkward if impossible to set on a system wide basis. It's also client behavior wired into every source-code built client. This should never, never, never have been the case: it should specifically require an extra, manual step to allow password caching, to force people to think about it and not do so by accident.

And while a "Keyring" or "Kwallet" can be useful, they are entirely reliant on GUI's to manage them, and do not in general operate on the command line. It's more reasonable to use svn+ssh, but there is no published management tool for handling user keys for that. (Git has gitosis, which works fairly well.)

This is one of the instances where Linus Torvald's description of Subversion being "CVS done right" is like gold-plating dogshit has real meaning. The security model was broken from day one.

Re:Git and Mercurial?

[Antique Geekmeister]

Or handling symlinks in svnadmin hotcopy, which fails silently and continues the rest of the operation successfully, last time I looked. It makes synchronizing pre-commit hooks or authorization setups among repositories quite awkward.

What's sad is that Linus Torvalds did most of this correctly, in far less time, than the Collabnet developers and their assistants. While git's 'branching' structure takes time to understand, the better security models, the performance, and far, far better support for remote development work win hands-down.

Re:Git and Mercurial?

[Antique Geekmeister]

No. I've used it, I've worked with it, I've cleaned up after it, and I'd rather date John McCain. The svndumpfilter command is an absolute trap for the unwary. Its filtering is painfully slow, its options are not well explained, and the absolute hairiness needed to block out the "release directory 1.0 that was published on Jan. 1 with binaries and password files and CD images in it, but which got deleted and replaced on Jan. 2" is unspeakably nasty.

Frankly, I find that 'svnsync' gives far more flexibility than svndumpfilter. Now that they've fixed the EOL handling for it, it's a far more useful tool. But it's still painful, and it's a function that is required on a regular basis at large sites, to flush code from former employees, to delete projects which some fool decided would all live under a single master repository, etc.

svndumpfilter also requires taking the repository off-line to do the rebuild of the new repo, safely, or risks a start/stop/catch-up operation that also risks the entire repository. For a largish repository, that is hours of rebuilding and hours of downtime. That's completely unacceptable in a production environment.

Re:Git and Mercurial?

[MassacrE]

I find I spend _much_ longer with my work uncommitted in a system like svn, where typically I'm not allowed to submit partial changes which would break the unit tests or even compilation.

Making and publishing a developer/project-specific branch is what distributed version control systems were designed for. If the constraint was that individual branches weren't being captured, the system was being used wrong

Re:Git and Mercurial?

[EvanED]

The trouble with this is that you have to worry about your laptop crashing, being broken or stolen.

No you don't; you just do a "git push" when you get somewhere with internet. You have to do this anyway if you're working with other people.

Today, with a £30 usb wireless dongle, you can commit changes no matter where you are.

Where do you live that you can get internet access while on the bus?

I mean, I could, but only through a cell phone plan. And at 20-30 USD/month, that will very quickly become much more than £30.

The lack of internet access isn't a good enough reason to advocate a distributed VCS. They have plenty of other good aspects to them, but being able to easily hoard changes locally is more a disadvantage than anything.

I guess we have different opinions. For the sorts of things I work on (things that are just me, and relatively small groups of of people), being able to work disconnected is IMO probably the biggest benefit. (It's at least #2; if so, #1 is the fact that distributed VCSs are almost always much better at branching than CVS/SVN. But there's really no reason this needs to be the case while being able to work disconnected is basically an innate feature to DVCS.)

Re:Git and Mercurial?

[EvanED]

And at 20-30 USD/month, that will very quickly become much more than £30.

I'm sorry, I misspoke. 20-30 USD is what you will pay for internet access from your phone. From a quick read of AT&T's site, the cheapest reasonable (i.e. has a limit > 10MB/month) plan they offer that allows tethering is either $40 or $60/month.

Re:Git and Mercurial?

[Bacon Bits]

So it's on every backup tape. So what? Your code is on every backup tape, too, and that's a lot more valuable reason to physically secure your tapes.

If you don't trust your sysadmin, fire them. If they're malicious, they'll just change your password and do whatever they want, or create a new account and do whatever they want. Or just modify the data directly. As a sysadmin I don't want your password because I don't want the responsibility of caring for it, but don't think that the fact that I don't know it means I don't have access to everything you may ever possibly need or want. "LOL I'M ROOT" springs to mind. Your password doesn't protect you from your sysadmin. Neither does a modern encrypted file system (most EFS systems have master keys).

The permissions on the folder are 700. They are not world or group accessible. Heck, root would still need to chmod, chown, or su to access them. Even if your home directory is shared out, nobody has access to this folder and it's contents except you. This situation is exactly what 700 permissions are designed for.

I do not agree that the assumption that the home directory is an insecure location is true. If it is true, then all your systems are already insecure and there's nothing you can do to secure the system until you correct that. More to the point, it's not Subversion's fault nor Subversion's job to secure your home directory. That's the OS's job.

Are you afraid someone will steal your laptop and access the password? Well, then they have access to all your data, too, which should be just as much of a concern so you ought to be encrypting the disk.

Are you afraid someone will access your system when you're not there? Logout or lock the system.

Do you not trust the admins? Why are they admins at all then? Data is more valuable than passwords, and they'll still have access to that.

I'll accept the argument that caching should probably not be enabled by default, though.

Security is the job of the operating system, not the application.

Re:Git and Mercurial?

[andi75]

I'm torn between modding the parent and emphasizing this is exactly what subversion was designed for.

If you make any changes that take longer then 1-2 hours to complete, start a branch.

I assume you macro'd @@ to be your svn root

Make your branch:

svn copy @@/trunk @@/branches/feature_xyz_branch
svn copy @@/trunk @@/tags/starting_feature_xyz

Switch your working copy to the branch (if you don't want to check out a new one, useful for large repositories).

svn switch @@/branches/feature_xyz_branch

Develop your features in peace. Commit into your branch whenever you made a meaningful change.

And when you're done, it's time to merge your change into the trunk:

svn switch @@/trunk
svn merge @@/tags/starting_feature_xyz @@/branches/feature_xyz_branch

Resolve the conflicts, test and finally commit into the trunk.

Congrats! You've successfully developed feature_xyz without every missing the benefits of a version control system.

Re:Git and Mercurial?

[Beezlebub33]

I've never understood conceptually the benefit of distributed RCS's over a server based one. People say it is better, and I'm reading this thread to try to understand how it is better, but I'm just not getting it.

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.

Is this it? Why is this a function of the distributed nature of the RCS?

Re:Git and Mercurial?

[Anonymous Coward]

It's different because SVN sucks. SVN branching is a heavy operation. SVN merging is heavy and fails on just about anything.

Re:Git and Mercurial?

[gbjbaanb]

RE: git-push, this is the same with all VCSs, until you commit to a remote repository your work is in danger. The difference between DVCS and traditional ones is that you *know* its not committed until you commit it, with a DVCS some people will think that its safe once committed, not realising its not safe until its pushed upstream.

Internet dongles... Vodafone sells one in the UK, £39 for the dongle, comes with 1GB transfer, operates over 3G or GPRS. The other carriers sell them, and give a lot more transfer capacity, but they expire after a month. You can get them on a plan as well, but given how little I use it away from a ethernet cable it's very cost effective (assuming you don't surf youtube using it). Surely they sell such a thing in the USA?

DVCS advantages are in merging (SVN branching is really good - its very easy, the problem is merging back). The real advantage is partly due to the source being local (but if you have a 12 Gig repo like I have, that's not such an advantage), and partly due to some SVN design issues - but the latter are being worked on, and even then DVCS merging is still not as good as Clearcase.

Re:Git and Mercurial?

[jsight]

Exactly... dvcs doesn't stop you from pushing into a branch on the "server" periodically. In fact, it encourages it.

I'm much more likely to keep stuff out of CVS/SVN for much longer periods of time, because the branching process is so much more time consuming.

Re:Git and Mercurial?

[CarpetShark]

Mercurial is a distributed system, Subversion is centralised. They suit almost totally different workflows and teams

No, centralised version control is a subset of decentralised version control. Subversion doesn't support different workflows/teams; it supports LESS.

Re:Git and Mercurial?

[jsight]

> Is this it? Why is this a function of the distributed nature of the RCS?

It's not. But essentially all DVCSes have decent (to great) merge tracking, which makes this possible. It could be done with a centralized system too.

The other big benefit is pure speed. Try switching branches on a DVCS local repo a few times, and you'll realize very quickly what a difference this can make.

Re:Git and Mercurial?

[godefroi]

It's not that the developers refuse to implement the "obliterate" feature (that's what they refer to it as), it's that noone's come up with a workable design for the feature yet, and noone's offered to do the work to implement it. If you really want it, put your money where your mouth is, and I'd be willing to bet you could get it implemented in short order.

Re:Git and Mercurial?

[Penguin's Advocate]

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.

I don't know where you work, but at my company losing half a day of one developer's work would be a huge deal. We're required to check in all of our work *at least* every couple hours. If it's not done, we need to check in a patch. There is no legitimate reason here for a developer to lose more than 2 hours of work. You'd be reprimanded for doing that once, and fired if you did it again.

Re:Git and Mercurial?

[JohnFluxx]

Wow, your place of work sucks. Seriously - forced to commit every 2 hours? Wow.

Re:Git and Mercurial?

[Anonymous Coward]

It's a bit unfair to keep blaming Peter Noone for not implementing features in Subversion. He's a busy man.

Re:Git and Mercurial?

[Anonymous Coward]

Is this it? Why is this a function of the distributed nature of the RCS?

when you have 100s of distributed repositories that eventually need to be synchronized it is a useful feature to have.

personally I like them for the simple benefit that I can commit locally without being connected to a central server. And easily review my changes throughout the day. I get interrupted at work a lot and tend to lose my place.

Re:Git and Mercurial?

[turbidostato]

"Then make that policy."

I do. Thus, I use tools that make it easy to follow the policy, not going against it.

Re:Git and Mercurial?

[turbidostato]

"I find I spend _much_ longer with my work uncommitted in a system like svn, where typically I'm not allowed to submit partial changes which would break the unit tests or even compilation."

That's a matter of policy, of a wrong policy, I may add.

Each commit must make sense by itself but there's a lot of things that make sense that still won't compile. On the other hand, I've seen quite a lot of times that even with "commit only when compiles" policies in place, it is the developer at fault trying to make cathedrals when huts were asked. Should I have to enforce a "commit only when compiles" policy (if it indeed makes sense it must be because limitations on the SCM tool) you can bet it wouldn't come alone but aside with a "and you must commit at least once a day" one.

"Making and publishing a developer/project-specific branch is what distributed version control systems were designed for."

Not. They were designed to allow disconnected/independent traced development. Not a thing I see valuable for a single company project most of the time. On the other hand, per-developer branches is a clear indicator something is not working properly on the development process. Per-feature branches? usually OK, Per-developer? Ask why and ask it twice (while, obviously, the ocasion may arise where one feature is developed by a single person). And usually, too much branches are again symtompt of poor development processes (like trying to make the tip of the main branch to always compile).

Re:Git and Mercurial?

[EvanED]

RE: git-push, this is the same with all VCSs, until you commit to a remote repository your work is in danger. The difference between DVCS and traditional ones is that you *know* its not committed until you commit it, with a DVCS some people will think that its safe once committed, not realising its not safe until its pushed upstream.

Getting your code to a server that is well-and-truely backed up and such is only a small part of why you commit. You also commit so you can look at the revision history; you also commit so that one commit == one change; you also commit so that you can make experimental changes locally but don't want to wipe out a legitimate fix.

I like fine-grained commits (that one commit == one change), and I have a fairly long bus ride in. There have been times where I've wanted to do two or three commits during a single bus ride.

As for the user getting confused... well, let's just say that you have less faith in the developers than I do. This is not a hard concept to get used to, even if you're used to the centralized model. Personally, I suspect you're far, far more likely to forget to CVS ADD a file (if I had a dime...) than to forget to push upstream.

Surely they sell such a thing in the USA?

I'm not aware of any, and I'd be very surprised given what a clusterfu*k our wireless service here in the states are.

Re:Git and Mercurial?

[skeeto]

Distributed revision control systems allow for history modification, but at the same time are much more immune to tampering than Subversion. That's because the ID for a commit is the hash of the entire history of that commit. Therefore if you know your HEAD ID, it's impossible for someone to tamper with your repository, accidentally or intentionally, without you knowing about it. It's cryptographically secure, not just an access control thing. And because each checkout contains the whole repository it's very unlikely that data will actually get lost in case of tampering: lots of backups all over.

So with distributed VCS there is "absolutely no way to screw up stuff that was committed", but in Subversion it's actually not too hard to screw up.

Re:Git and Mercurial?

[Eivind Eklund]

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.

The question isn't who is at fault - the question is which combination of tools, policies and people tend to give what results. If one particular tool tend to lead to one particular behavior, that's a fact about the world - and disregarding this fact when designing a development environment is a recipe for trouble.

Different tools lend themselves to different kinds of use; a scalpel lends itself to a precise cut (but is slow for large cuts), a butcher's knife lends itself to a rapid cut (but not as precise). The cuts of each could be done with the other and enforced with a policy - but it's better to give a tool that leads to the kind of behavior you want.

Re:Git and Mercurial?

[David Gerard]

Git is increasingly popular with large Unix-based projects. It's frequently Just The Right Thing if you have a huge monolith of a project which lots of people want to work on. e.g. Xorg, Wine.

Even on Wine - where every single patch goes through Alexandre Juillard - git is highly usable and highly testing-friendly. Turns out one of the killer features for Wine is git bisect for regression spotting :-)

Re:Git and Mercurial?

[David Gerard]

My most recent workplace is still trying to shift the developers from CVS to Subversion ... if we gave them Git you bet they'd work out how to shoot their own legs off with it.

Re:Git and Mercurial?

[David Gerard]

+1

Wine has a single codebase and a single lead developer pushing every single patch. Git is working really well for it. It's really very easy to use.

Turns out the design criterion "let Linus do his job and don't piss him off" works out well for lots of other people too!

Re:Git and Mercurial?

[David Gerard]

I disagree. CVS/svn worked well in my last workplace in two use cases:

1. A project which largely has a single developer working on it. (Lots of those.)

2. Something with several developers, but very slow code changes and much discussion before even those. (Much of the stuff us sysadmins were doing.)

Any version control is a vast improvement on none, and svn is fine at being svn. But it's the last of its line.

Re:Git and Mercurial?

[David Gerard]

CVS to svn is a big step? I'm surprised ... I did a lot of porting of old code from CVS to svn to continue work on it (cvs2svn Just Works) and the only difference in working practice was having to occasionally use the svn cheatsheet to get the exact wording of the command. What bits were big changes?

Re:Git and Mercurial?

[David Gerard]

ah, OK, that answers my question above :-)

Re:Git and Mercurial?

[EvanED]

What bits were big changes?

The changes I care about?

• Actual changesets (so no more of tools saying "well, these two files were updated at about the same time with the same log message, so they're probably part of one logical commit)
• Consistent numbering across versions (so you can just refer to a number instead of a time if you want the revision as of a particular point). Related to the first point; they're sort of two ways of looking at the same issue.
• You can actually do some stuff (in particular diff and stat/-nq up) without repository access (big for me because of me doing a non-trivial amount of work on the bus with no internet access, and also being too lazy to figure out how to get TortoiseCVS to not ask me for my SSH password every time)
• You can rename files without losing version history across the rename. (SVN isn't quite ideal here; other systems do it better. But it's still way better than CVS's "delete the file and make a new one".)
• Directories are versioned, so you can delete directories for real (instead of the "empty directory is not there" CVS thing, which causes a few problems), rename directories without going through a crapload of hassle, etc.

• All of these are, IMO, pretty significant benefits to Subversion over CVS.

Re:Git and Mercurial?

[David Gerard]

Oh yeah :-) I thought of that stuff more as "hmm, the pain in my forehead seems not to be there."

Re:Git and Mercurial?

[Informative]

Inside Sun we have used the TeamWare DSCM for many many years, and it has allowed us to co-ordinate distributed development between teams, both remotely and locally. The Mercurial DSCM will make this work even better, and allow anyone to join in, at the appropriate level and area.

http://www.javalobby.org/java/forums/t103115.html
OpenSolaris is using Mercurial, as is Java 7.

Re:Git and Mercurial?

[Antique Geekmeister]

It's been _8 years_ in the bug tracking. Given the refusal to handle this, and the sad excuse for a security model that is enforced by the lack of critical features for Subversion (such as a sensible dedicated shell for shared SSH clients or a usable client manager for SSH keys), there is _no reason_ to waste my time trying to follow their rather complex and personalized C++ coding models to achieve this one of a set of major drawbacks to the system.

I'll recommend git, which I've used directly as a straightforward upgrade from subversion, and support subversion as a legacy onlyo. (And yes, I've published patches for subversion in the past, some of which were accepted.)

Re:Git and Mercurial?

[Antique Geekmeister]

Sir or madam, I *KNOW* that someone malicious will try to steal by laptop and backups and on-line access. They're the warrentless and provocation-free goons at the NSA and the FBI, the script kiddy who borrows her dad's computer and pokes around the work network inside the VPN with it, the idiotic systems administrator who says "we trust the people we work with and therefore don't need to install patches inside our network", the middle manager who can't believe that security of the tapes themselves is as important as security of the network, etc., etc., etc.

No, I don't trust the admins. We, as admins or technically adept people, _should not have_ access to the selected passwords of other users. We don't need them, and knowing them simply makes us more responsible for their potential foibles or more tempted to go poking into insider trading email or personal files. I absolutely _do not want_ to know their passwords: that way I can't be subpoenaed for them, either.

Re:Git and Mercurial?

[Anonymous Coward]

> Are you afraid someone will steal your laptop and access the password? Well, then they have access to all your data, too, which should be just as much of a concern so you ought to be encrypting the disk.

So by that argument everyone should store their bank account details and PIN on their PC's, too, after all they already have those valuable games saves already there unencrypted.
And no, if you work on a public OpenSource project it is of no concern that a thief has access to that data.
Most people may also have other valuable data on there and even unencrypted, but that still remains a conscious decision to accept that risk, silently stored passwords are certainly are _not_ part of that decision.
I have often only noticed that I had the SVN password lying around after wondering why my patch was suddenly committed, without the password (and in some cases that deprived me of the critical extra second to abort a bad commit e.g. because of a typo in the commit message I only realized shortly after closing the editor).

Re:Git and Mercurial?

[orzetto]

No. I've used it, I've worked with it, I've cleaned up after it, and I'd rather date John McCain.

I did not say it was pleasurable, I said it was possible. My point being, I'd rather go for a solution that makes removing data a difficult administrative operation, rather than one that makes it easy for any user; for it is bound to happen, sooner or later, that Joe Schmo, having committed an entire DVD by mistake, mistypes the wrong revision number and obliterates the current HEAD. Why would I risk that?

Re:Git and Mercurial?

[Antique Geekmeister]

Because in any reasonably sized encironment, the likelihood of large insertions of inappropriate material grows to a certainty. And while I have no issue with it being an administrator-driven command to obliterate such material, for example under the 'svnadmin' command, it should not require the hours of dump and rebuild time necessary for even a modest sized, 10 Gig software repository, to delete a single accidentally stored core file or ISO image that may accidentally comprise more than 10% of its bulk.

It is one of the most requested features for Subversion. Subversion is the _only_ contemporary source control that has no graceful means to actually delete data. There has been no progress towards it in 8 years. That tells me they made a very, very bad original assumption about how things work, similar to the one they made about storing user passwords in cleartext, silently.

Re:Git and Mercurial?

[jgrahn]

Any version control is a vast improvement on none, and svn is fine at being svn. But it's the last of its line.

I doubt it. Not because the SVN/CVS model is so great, but because there's for some reason so much ideology and flag-waving in this. Let someone start using SVN, or git, or whatever, and suddenly it's as if he's joined some fscking religion.

So when you say SVN "is the last of its line", I hear "Jesus is coming soon!".

Me, I use CVS at home and ClearCase at work. I like both of them. The main problem is not the tool, but people setting up processes which destroy any benefits from the tool, and users then deciding the tool is crap, ignoring it for as long as possible.

Re:Git and Mercurial?

[Haeleth]

Perl, too.

It's a small subset of open source projects, but it includes many of the biggest and highest-profile ones. Where they lead, others will follow.

I don't know that GNU will, necessarily, though. For example, GNU Emacs is currently moving to Bzr, though they do also provide git access.

Re:Git and Mercurial?

[Anonymous Coward]

The permissions on the folder are 700. They are not world or group accessible. Heck, root would still need to chmod, chown, or su to access them.

You're kidding aren't you? root can access the file and directory without having to do anything that you list.

Re:Git and Mercurial?

[David Gerard]

I mean that I can't really imagine centralised version control going much past Svn.

I've used ClearCase. (I have an alleged qualification in it, which I call "alleged" because Rational's courses are utter bollocks.) It has some damn fine concepts, only ruined by for some reason having to reimplement half the bashutils in its command interpreter, badly. And the GOOD LORD YOU'VE GOT TO BE FUcKING JOKING price tag.

Re:Git and Mercurial?

[aevans]

One problem with svn is that it has recently become abandonware. Or rather, collabnet has stopped supporting open source subversion, and does their best to prevent you from obtaining it. As a result, subversion is effectively dead on the vine. And when the major tools vendor for Subversion clients (Eclipse) is so buggy that you're bound to get a corrupt local repository on newer version of Eclipse (with subversive or subclipse) there really isn't a a good reason to use it.

Many choices, not mentioned here.

[Anonymous Coward]

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.

[kabloom]

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).

Re:Many choices, not mentioned here.

[gwern]

The author of the OP article, bos, most certainly does understand the Darcs model, having used it often as he has long been part of the Haskell community (as his bio reveals); his point is that other people may not. (Personally, I think in comparison to Git's model, Darcs is a miracle of clarity. But reasonable hackers may differ.)

Re:Many choices, not mentioned here.

[De Lemming]

Indeed, I was wondering about Bazaar (bzr) in particular. TFA assumes "Each tool emphasizes a distinct approach to working and collaboration, which in turn influences how the team works."

But the very first line on http://bazaar-vcs.org/ states: "Bazaar is a distributed version control system that Just Works. While other systems require you to adapt to their model of working, Bazaar adapts to the way you want to work, and you can try it out in five minutes."

An overview of different possible workflows is given on this page. The most simple solutions don't need a server at all, you can use a centralized repo like svn/cvs, or more complicated distributed setups (like with git/hg) are possible.

Question about subversion

[darkwing_bmf]

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

[PotatoFarmer]

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

[JohnFluxx]

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

[koiransuklaa]

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

[Jack9]

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.

Re:Question about subversion

[Ed Avis]

Copy files as you like, but don't copy and don't touch the .svn metadata folders. (So in particular don't just copy a whole directory and everything in it.) Regularly do 'svn status' to warn about files which are in your working copy but not known to the repository, files with changes that haven't been checked in, and so on. Then you should be fine. Optionally, set up 'svn ignore' to not warn about object files or other bits and pieces that may be in your working copy without needing to be checked in.

Errata

[kabloom]

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

[kabloom]

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

[aurelianito]

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

[forkazoo]

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

[kabloom]

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

[Anonymous Coward]

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

[shawn(at)fsu]

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.

Re:Errata

[gbjbaanb]

No, SVN will never commit changes if your working copy is out of date. it may merge the repository changes in automatically for you, but the OP was wrong - it will not overwrite already committed changes.

Re:Errata

[Ed Avis]

No, the statement is quite correct. (And your statement 'Subversion requires you to update... whenever you have modified a file that has changed' is also correct.) Suppose the repository contains two files foo.h and foo.c. Bob modifies foo.h and checks it in. Separately, Alice modifies foo.c and checks it in. Subversion does not require her to update her working copy first; she can check in the file without any warning. But now the server has a new tree that doesn't match either Bob's tree or Alice's tree. They could both have run the test suite before committing and seen it pass; but the current version on the server might fail. (For even more concreteness, suppose foo.h defines an unused constant 'const int FOO_FACTOR = 5'. Bob checks in a change to remove it. Alice, meanwhile, edits foo.c and starts using FOO_FACTOR in the code. Both people are checking in working code; both Bob's tree and Alice's tree are working programs. But the state that ends up on the server is neither of those, and is a program that won't build.) I am not saying this is good or bad, just saying this is how Subversion works.

Re:Errata

[Beezlebub33]

Thank goodness your test code will catch it!

Re:Errata

[Anonymous Coward]

No, the GP is correct. As you point out yourself, subversion ONLY forces you to update if you modified some files that have been updated. Thus, if Alice modifies and commits file A, and Bob modifies and commits file B without updating, the repository will contain versions of A and B that nobody has ever seen or tested together.

Re:Errata

[liquiddark]

They don't have to see the changes. SVN will merge silently on update. It'll be on the client, but frankly it's very easy to get into the pattern of commit->fail->update->commit.

Re:Errata

[slashdotjunker]

Whoosh!

The GP was correct. Let's say we have a project with 2 files: foo and bar. Here is the repository, version 1.

Repositiory, foo:1, bar:1 (tested and working)

Alice and Bob check out the project.

Repositiory, foo:1, bar:1 (tested and working)
Alice, foo:1, bar:1 (tested and working)
Bob, foo:1, bar:1 (tested and working)

Alice modifies foo, tests her changes and checks in her work as version 2.

Repositiory, foo:2, bar:1 (tested and working)
Alice, foo:2, bar:1 (tested and working)
Bob, foo:1, bar:1 (tested and working)

Bob modifies bar, tests his changes and check in his work as version 3.

Repositiory, foo:2, bar:3 (untested!)
Alice, foo:2, bar:1 (tested and working)
Bob, foo:1, bar:3 (tested and working)

Do you see the problem now?

No they don't.

[SanityInAnarchy]

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.

[russotto]

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.

[Anonymous Coward]

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.

[SanityInAnarchy]

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.

Re:No they don't.

[Anonymous Coward]

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.

[SanityInAnarchy]

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.

[Anonymous Coward]

You can branch to your heart's content in Subversion. There's nothing stopping each user from branching off the trunk, working only in their branch, then merging to the trunk when they feel like it. The only difference is that Subversion is centralized, so you need a network connection to the server to commit. For most companies and users, this isn't a problem.

Re:No they don't.

[scotch]

In his Google Tech Talk on Git, LT was an asshole.

There, fixed that for you.

Re:No they don't.

[TheThiefMaster]

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?

Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?

To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable, as long as you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.

Re:No they don't.

[Anonymous Coward]

1. You can refer to trees using various time limits: "git log --until="2 weeks ago"
2. incremental order just doesn't work when you have branches that get merged (see SVN for a total failure at this)
3. Why would you have a hash in the filename? Feel free name your tar-files / packages by the date if you want to...

Re:No they don't.

[Anonymous Coward]

Everyone's doing it, which has a network effect

For some 'everbody ~ 1'?

Re:No they don't.

[wrook]

This is a stupid "me too" post, but hopefully it will lend credence to what you say.

I originally used SVN because at the time there weren't any other credible options. I moved to bzr because I wanted distributed version control and bzr's syntax seemed easier than Git. Now I'm in the processes of moving over to Git. Git's documentation has vastly improved and that's a big reason for my change. I can't even really understand why I thought it was more difficult than bzr now. I also think that if people tried Git they would find it easier to use than SVN in almost every circumstance (there are a few counter examples, however).

The SHA1 hashes may look scary at first, but it really is the best approach. Incremental revision numbers are meaningless because there's no way to determine the order of the revisions on the distributed branches. For important revisions on a public repository you can always use a tag.

Like you, one of the main features of Git is that I can understand what it's doing all the time and why it's doing it. Again, kudos to the people who improved the documentation, but a lot of this is also just good design.

Re:No they don't.

[SanityInAnarchy]

You can branch to your heart's content in Subversion.

Which is useless if you can't merge.

Git branches are not only much lower cost at the beginning (the command runs faster and is easier to use, and other users don't have to know about your branch until it's ready), but they merge much more easily.

The only difference is that Subversion is centralized, so you need a network connection to the server to commit.

Well, and that if the network connection or the server goes down, I can't work.

But to say that distributed is the only good thing about Git would be like saying that centralized is the only good thing about SVN.

Which would you rather use, SVN or CVS?

Then you can understand why I'd rather use Git, even in a centralized environment. In fact, I'd say the productivity gains for Git over SVN are probably greater than those of SVN over CVS.

Re:No they don't.

[PeterBrett]

Well, except that SVN revision numbers are in order. Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer? What about with an svn revision number?

You may wish to investigate the git describe command. For example:

[peter@harrington git (master)]$ git describe
v1.6.3.2-225-gb836490

The output contains the latest annotated tag, the number of commits since that tag, and the first 7 hex digits of the current commit hash prefixed by a "g". All the information you need to quickly or precisely identify a revision.

Documentation is here.

Re:No they don't.

[SanityInAnarchy]

Could you tell at a glance which of two binaries with the git SHA1 hash in the filename was newer?

No, but I could tell with a quick 'git log' of each.

Can you tell me when I would ever, ever need this? I never look at revision numbers outside of a log anyway. The last time I can remember caring what those numbers were, or holding them in my head for longer than a copy/paste (if that), is when I had to manually feed revision numbers into 'svn merge'.

Well, guess what? 'git merge' is smart enough to not need that. The "merge tracking" feature of SVN that's supposed to give it similar functionality also slows it down insanely -- merges should take seconds, not half an hour.

To me, it would make more sense if there was an incremental part to a git changelist id, even if it was "number of seconds since 2000" or something else unreadable,

Congrats! Two coders have now created exactly the same revision number, by committing on the same second!

Never mind that those are not exactly easy to tell, at a glance, which is greater. The epoch time now is 1251278556. Now it's 1251278604. Can you tell "at a glance" which is greater?

In fact, want to race? I bet I can run two 'git log' commands in the time your "glance" takes, with numbers like that.

you could ask someone "which revision crashed" and get back an answer you could easily use to tell if they were up-to-date or miles out of date.

If you're talking about programmers, just tell them to pull and try again -- it won't take long, and it won't break anything. Or ask them to run 'git log', and you'll get a date and time.

If you're talking about end-users, may as well put a date and time in the build, as part of the "version" information.

Re:No they don't.

[SanityInAnarchy]

The SHA1 hashes may look scary at first, but it really is the best approach.

This is the only thing I'm not sure I agree with -- SHA1 is kind of weak by now, and it was already old-ish when Git was written.

But I definitely agree on that much -- I prefer a globally unique number (though maybe a GUID would be better?) to a kludgy attempt at preserving revision numbers.

There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it. But I'm starting to realize I'm about as likely to hack on Git as I am to hack on my filesystem -- rather than link against it, I can always write a script that calls git commands.

Re:No they don't.

[ztransform]

There was actually another reason I preferred bzr -- it's written in Python. Git is written in C, Bash, and Perl, which means a lot steeper of a learning curve if I were to ever hack on it.

Personally I find C, Bash, and Perl much simpler to understand and deal with.

Re:No they don't.

[Anonymous Coward]

If you can't merge you are a moron. I don't get whats so difficult about merging with SVN. You checkout the branch where you want the merge applied. You get the changes from the branch you want to merge. You run your tests to make sure everything works. You commit the changes.

Re:No they don't.

[Lally Singh]

But some setups are better with a centralized setup.

Merging isn't pretty. There are three things that help:

1. Everyone tries to work on their own files
2. ediff
3. Unit tests to make sure the merge didn't screw something up.

Re:No they don't.

[Nevyn]

Well, except that SVN revision numbers are in order.

If you only use a single branch, then I guess that might be true. But the only reason you'd be doing that IMO is because SVN is utterly worthless at managing branches.

Re:No they don't.

[SanityInAnarchy]

But some setups are better with a centralized setup.

So you run Git on a centralized server. Why are we still talking about this?

Subversion can do centralized or centralized. Git can do centralized or distributed, and it does centralized much better than SVN does.

Re:No they don't.

[SanityInAnarchy]

I don't get whats so difficult about merging with SVN.

That's like saying, "I don't get what's so difficult about piping wget through less." It's not really difficult, per se, and it can be done -- and, in fact, I've had reason to do so -- but would you really prefer that to a modern web browser?

You may think I'm exaggerating. I'm not. SVN really is that bad, and Git really is that much better.

You checkout the branch where you want the merge applied. You get the changes from the branch you want to merge.

Right. How do you know which changes you want?

Well, either you run 'svn log' in both branches, trying to figure out when they were last merged, and write down the revision numbers in question, then paste those, along with the repository URL, into something like: "svn merge http://example.com/app/branches/foo -r1234:5678"

Or you turn on merge tracking and let SVN take 20 minutes or more to find out the same information. And then take another 20 minutes or more if you don't successfully resolve conflicts as it's trying to merge.

You run your tests to make sure everything works.

You left out "spend 5-10 minutes sifting through conflicts that Git would've avoided." Sure, Git has conflicts, but you end up with much fewer than with SVN.

And for the record, yes, I am comparing apples to apples. I worked on a system in SVN for over a year. Then I migrated to git-svn. It was like night and day, even still syncing to the SVN server, even with the exact same project.

Re:I'd suggest Git

[CarpetShark]

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 ;)

Version Control Systems all have one thing

[MerlynEmrys67]

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

[mandolin]

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

[Anonymous Coward]

Actually, no, they don't all suck.

Re:Version Control Systems all have one thing

[Gr8Apes]

There's not an SCM system made that doesn't suck that I'm aware of. Having said that, I've not used Perforce nor Git. Git has no real integration with my IDEs of choice, and Perforce I only have second hand info on, but former co-workers that have converted to it seem to not be sold on it either. I have considered writing my own, just lack the 8 solid months and desire to do such a thankless task.

I have had the pleasure of using, in no particular order: StarTeam, SVN, CVS, MKS, and ClearCase. SVN was by far the easiest to use while actually performing basic SCM functions adequately. ClearCase was the best at dealing with branches. They all suck, however, and are only used because there's a lack of anything better at an acceptable price, or even unacceptable price (ClearCase and Perforce are certainly at the top end).

VSS is bar far the worst and should be considered a tool of sabotage at best. CVS and MKS both share the inability to do atomic transactions. Nothing, and I mean nothing, will ruin your day like a file that's listed as checked in, logged as checked, but was never actually commited to the repository...

And as far as branching goes, the only one that's even in the ballpark is ClearCase.

Picking an SCM system is more about picking your least pain than picking something that actually helps your process. There has been no innovation to speak of in the last ten years, or 20 years, for that matter as most of these systems cores date back 20 years.

Re:Version Control Systems all have one thing

[scotch]

Actually, yes, they do all suck.

Boy, this is fun!

Re:Version Control Systems all have one thing

[hysterion]

I've not used Perforce nor Git

There has been no innovation to speak of in the last ten years

Self-destructive argumentation, on the other hand, is progressing faster than ever!

Re:Version Control Systems all have one thing

[Goetterdaemmerung]

After getting used to it, I really liked ClearCase. It's an incredibly powerful tool. Although I was always amazed how people tended to muck it up by doing things such as copying files and then re-adding them to source control in a different directory, thus causing evil-twins (two different objects with the same name can't be merged). One time someone was trying to rename a file, but it had an error causing both filenames to exist and to point to the same file object... That was fun to understand, but really easy to resolve by restoring a previous directory point.

 

Anyway, your use case of ClearCase sounds incorrect. It is true that if you are working in the same branch/stream as another developer, their checkins will instantly appear in your view, which could obviously break you. The proper use model is to create private branches for each developer. This allows you to control when you pick up others' changes as well as control when your code is "good enough" to be delivered to everyone.

Re:Version Control Systems all have one thing

[Anonymous Coward]

I actually ran into evil twin a week ago. The way we have our system setup it is necessary at some times to do evil twin. This being that we can have branches of source driver releases from our driver team. So say we have v1 driver release, a patch is checked in based on that because some products are using the v1 drivers, then we also get a similar patch for the v2 drivers because the same problem exists. V2 exists on the driver vob on top of V1, but some products are held back for stability and testing so they dont move to V2 at the same time as others. Neither of these patches officially go in but because they have the same names and exist on the same branch Clearcase freaks out. It can be a pain in the ass when you mean to do it on purpose.

Re:Version Control Systems all have one thing

[koiransuklaa]

I have had the pleasure of using, in no particular order: StarTeam, SVN, CVS, MKS, and ClearCase.

No offence, but hysterion is right: you are not in a position to comment on VCS innovation and have only yourself (and possibly your employer) to blame for a major part of the pain you have to endure.

Re:Version Control Systems all have one thing

[theCoder]

Were you using ClearCase on Windows? It's definitely an order of magnitude slower on Windows than it is on Linux. On Linux, it seems to be about as fast as the NFS mounts. We typically don't store anything local on our UNIX machines, so even snapshot views (the "check your view out to a local place on the HD") would be over NFS, and those have their own problems (like long update times). However, on Windows, snapshot views are the only way to get anything done. I'm not sure if it's a problem with the ClearCase driver or a problem with Windows internals (making too many calls or something).

However, ClearCase does tend to get slower over time as you accumulate more branches, labels, etc. There doesn't seem to be any way to overcome this problem. Even obsoleting old branches doesn't seem to have a noticeable effect. I think this is because they are still there, even if they are read only. But we don't want to delete them, because it would mean losing that history.

ClearCase also has a steep learning curve (probably more than git). It took our group a couple years to get a good process working (along with scripts). Now, we chug along pretty well, even if it's not always efficient. We know the drawbacks and what to avoid, and it's rare to have major problems anymore. I think our group would benefit from a distributed model like git (if nothing else, I've heard it's fast), but changing systems is very difficult, expensive, and time consuming. That, and the only reason we use ClearCase is because it's the Corporate Standard, so I don't think we could get away from it even if we had the time, money, and people.

Re:Version Control Systems all have one thing

[Gr8Apes]

>

Self-destructive argumentation, on the other hand, is progressing faster than ever!

as are vapid empty statements!

Re:Version Control Systems all have one thing

[Gr8Apes]

I'm still looking. Name me something that can be used today for my particular needs and I'd be happy to look at it. That would be more useful instead of just engaging in weak insults.

Git does not fit my needs. Cost is a constraint. Not just cost of the software itself, but implementation, configuration, management, training, and maintenance. Most of those should be low with little time impacts on most of our developers. And then there are the functional requirements: reliability... heck, if it's not reliable (StarTeam, CVS, MKS, and VSS especially) it's just a wanna be.

So step up and offer a solution that meets these needs and I'll be happy to try it out. Otherwise, my statement stands that there is no innovation worth speaking of in the SCM field. I'm not interested in school or niche projects that will never see commercial use. I wouldn't bet my company on such an item, and neither will anyone else with a smidgen of intelligence and common sense.

Remember: SCM is merely a tool, not an end.

Re:Version Control Systems all have one thing

[koiransuklaa]

There was no insult in my post, sorry if it seemed that way. You mentioned the systems you use and that list is mostly totally irrelevant to todays version control. After that you have no basis for complaining about the lack of innovation.

More specifically: CVS is ancient, broken and slow to the point of unusability. VSS is clusterfuck, we agree on that. Implying that either of these is more reliable than git is a claim that really needs some backing up... MKS and StarTeam I have no first-hand experience with. I admit I've never even heard of MKS Source (and neither have my colleagues), but the fact that it doesn't do atomic operations makes it a toy, in my opinion. StarTeam on the other hand flunked on the first test I had: "How do I get my data out of there" so I didn't look further.

Clearcase is the only thing in your list that has some merit... It actually sort of works and has some nifty features no-one else has. Still, normal usage is a pain compared to git: it's slow, it doesn't work offline, multi-site support is a joke and it's sloooow. Apparently it's also an asolute pain to maintain. Did I mention it's dog-slow? In any case, there is a reason why git-clearcase bridges are so popular: people who are forced to work with clearcase use git to hide the uglyness...

Now to your comments:You say that none of the new SCMs do what you want. Fine, but that does not mean that there is no innovation in the field... Shouldn't that be self-evident?

As to the problems you see with git: I believe you said git does not meet your needs wrt to implementation, configuration, management, training, maintenance or reliability. Without _any_ details that's just fluff... I have no way to answer that.

Still, some comments: Training is a given, but I assume you didn't expect innovation without any changes. Reliability: suggesting that git is unreliable and implying CVS and VSS are, is just totally absurd in my opinion.

Remember: SCM is merely a tool, not an end.

Yeah. I take pride in the work I do and expect the best tools available. If my employer told me to work with CVS, I'd probably start looking for a new job. Not because working with CVS is impossible but because it's just a really, really bad sign if an employer doesn't give a skilled worker the best tools available... Linus said it better than I can:

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is.

Re:Version Control Systems all have one thing

[Gr8Apes]

(RE CVS/VSS)...Implying that either of these is more reliable than git is a claim that really needs some backing up

I made no such claim. I did imply that both them and MKS are completely unusable due to lack of atomic operations and other issues.

Clearcase ... actually sort of works ... normal usage is a pain

Yes, CC is an absolute pain to use for those new to it. It can take an easy 6-12 months just to get up to adequate speed with it, if you're using a slightly more complicated system. It also requires a real administrator to operate even remotely decently.

multi-site support is a joke

Apparently someone forgot to tell us this as we worked in 5 sites across the globe. Maybe you needed a better administrator? (Yes, ours was paid more than all but the top developers)

Now to your comments:You say that none of the new SCMs do what you want. Fine, but that does not mean that there is no innovation in the field...

After re-reading my comments, I suppose I wasn't clear enough: There is no widely supported, easy to use and maintain form of SCM currently available.

Hopefully we can agree on that. Git, your apparent favorite, is nowhere near mainstream.

Still, some comments: Training is a given, but I assume you didn't expect innovation without any changes.

True innovation would be a painless SCM. The changes I'd expect would include less work and training, not more.

Reliability: suggesting that git is unreliable and implying CVS and VSS are, is just totally absurd in my opinion.

You said this, not I. I gave CVS, VSS, and MKS as examples of unreliable SCMs. VSS at best should be considered a tool of sabotage. Oh yes, 4 posts up the hierarchy, I said exactly that.

...If my employer told me to work with CVS, I'd probably start looking for a new job. Not because working with CVS is impossible but because it's just a really, really bad sign if an employer doesn't give a skilled worker the best tools available...

That's interesting. So what are the best tools available? Seriously. Just state it so we all know and can go home now. I merely stated my dissatisfaction with the current state of SCMs.

"More Popular"?

[adamkennedy]

> 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"?

[Anonymous Coward]

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

[ImustDIE]

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

[Rob the Bold]

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

[IMightB]

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

[Anonymous Coward]

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 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 quite properly notes that SCM "is not to be confused with revision control".

Re:TortoiseSVN

[walshy007]

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.

Re:TortoiseSVN

[Anonymous Coward]

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

[N7DR]

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

I beg to differ.

From http://tortoisesvn.net/node/58:
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

[Gr8Apes]

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

No they won't - SVN pretty much sucks all around. There'll be no wonder if Git's actually better. I've considered looking over Bazaar and AccuRev, but the latter costs too much, and I ran out of time for the former.

Re:TortoiseSVN

[Omnifarious]

I don't like git. I like Mercurial. I think Mercurial is a better choice than git in most situations.

Re:TortoiseSVN

[Bacon Bits]

I agree. I plan on sticking with SVN until TortoiseGIT hits 1.0. All my projects currently are personal projects so SVN is really quite easy to use, and that ease of use is completely due to TortoiseSVN. The fact that VisualSVN Server is so easy to set up and manage helps quite a bit, too. Once TortoiseGIT is released I'll get rid of my last Windows "server" and set up Apache+Git on Debian instead.

Re:TortoiseSVN

[Lally Singh]

Ugh, I can't stand Tortoise. It just *kills* the speed of my file-open/save dialogs. In exchange for a few labels (and not in visual studio! just the explorer) and right-click commands (hint: a menu and some dialog boxes do not constitute a GUI) I literally go get coffee when the dialog box is loading my checked-out repo.

psvn.el for Emacs, however, is an absolute dream. I see my repo (or subfolder thereof) as one dired-like list. diff, checkin/update, etc. are live and just update my buffer.

Re:TortoiseSVN

[Anonymous Coward]

You might be hitting a status cache problem. Google for "tortoisesvn slow status cache" and check out the configuration changes you need to make there. You can also disable the icon overlays to avoid this problem from TortoiseSVN Settings -> Icon Overlays. I think changing them from "Default" to "Shell" also fixes the slowness.

Re:TortoiseSVN

[complete loony]

On Windows / NTFS, subversion creates so many small files that are nearly identical between branches that there must be a better way to handle a local copy of the repo.

Personally I'd like to see someone write a file system driver to handle work folders. So you can browse into the repository and make changes to files without having to store a complete copy of each file for each cheap copy in the repository.

rawr

[Anonymous Coward]

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.

Re:rawr

[Rob the Bold]

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.

Talk to a lawyer

[FranTaylor]

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

Re:Talk to a lawyer

[Anonymous Coward]

the chief difference between legal documents and software is that eventually the software has to work.

Bazaar

[ggpauly]

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

Source Control Shingle

[acon1modm]

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

Least logical?

[FranTaylor]

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?

[Anonymous Coward]

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:Least logical?

[Anonymous Coward]

"It works" doesn't make it logical. That's a minimum requirement (unfortunately for varying degrees of "it works"). Being logical comes on top of this.

Re:Least logical?

[PeterBrett]

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.

I don't know if you noticed, but git seems to be doing pretty well for the Linux kernel. Admittedly, there are only thousands of developers simultaneously working on the project while many thousands of people are simultaneously checking out code to build. I suspect that p4 would rapidly choke and die if you tried to do the sort of scale and rate of development that the kernel maintains month after month.

Re:Least logical?

[macsuibhne]

There are a number of Perforce customers with thousands of users on a single server, and at least two with more than 5000.

how about the tps report system for each change

[Joe The Dragon]

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

[Anonymous Coward]

The more popular Git? since when

Re:Git

[Anonymous Coward]

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?

[gillbates]

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

Re:No mention of ClearCase?

[Anonymous Coward]

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

Re:No mention of ClearCase?

[William Ager]

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.

Re:No mention of ClearCase?

[Ztream]

I use Subversion on a daily basis, and I believe everything positive you said about ClearCase holds true for Subversion, except point 9. There are some philosophical objections to 9 (you should test the resulting code before committing it anyway), but I don't know if it's a design decision or a missing feature.

That's not to say that Subversion doesn't have problems of its own though, but using CVS as a representation of the state of version control systems is like judging proprietary software on the basis of Windows 95.

Re:No mention of ClearCase?

[Anonymous Coward]

ClearClase and CVS? Are you serious? have you been hiding under a rock for the last 15 years?

Re:No mention of ClearCase?

[Anonymous Coward]

I've used Clearcase, SVN, Git, and some CVS.

Note: I only have experience with raw Clearcase and not the UCS workflow.

Git is hands down the best. Clearcase has given me the most headaches out of any RCS I've had to touch.

"ClearCase can manage extraordinarily large codebases spread across several geographical locations."
Yes, it can manage huge code bases and allows checkouts of subtrees which Git doesn't allow (you can kind of hack around it with submodules but it's not the same), however, it is ridiculously slow. Making large code bases pretty much impractical to have. Almost every operation *requires* some network operation, the worst offense is that it needs to check with the licensing server. If you ever have the licensing server go down (impossible, I know) you pretty much shot off the balls of all your engineers until you get it back up.
Running clearcase update on any large project takes an inordinate amount of time as almost every single file has to be looked over (as opposed to git, where it maintains near instantaneous speeds on even large code bases).

"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."
You don't tag every commit though do you? Because what I have discovered is that some serious mangling can occur if you rename a file and a new file is created with the old file's name. I've found that this happens even if I am in a "private" branch.

Raw clearcaseadvocates the idea of checking out files (locking them from other devs) before working on them. This introduces a new level of RCS hassle as you end up bringing in some admin to help unlock files that some guy in the next cubicle forgot to uncheckout before taking the week off.
Oh yes, if you checkout files and then your computer dies..... better have your admin on speed dial.

"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."
I would like to mention that dynamic views also have a pretty bad disadvantage IMO. Since they are autoupdating, you can end up with some pretty nasty thrashing as your end up never having a specific version to develop against.

Ever try using the clearcase from the CLI? The standard tool you use to interface with clearcase is `cleartool` most people alias this to `ct` because no one wants to type it all out. However, nothing is going to be able to save you from 'ct ci -c "comment" `ct lsco -r -me -s`' (that is the short version). Yes, this does the equivalent of 'git ci -a -m "comment"'. Or not quit, because you may have "hijacked" files (edited files without checking them out first). In that case, you have to find all your hijacked files through some other obscure `ct find` command. Of course you could look at the documentation, the wonderful world of `ct man` where they reimplement `man` in tried and true IBM (ugly) fashion.

configspecs (how you specify which branch you are, what parts of codebase you have checked out) are also highly obtuse, creating your branches is a non-trivial operation, and raw clearcase versions by file, not changeset (bad).

I could go on.

Re:No mention of ClearCase?

[Anonymous Coward]

I will answer from Mercurial POV, but everything applies to Git too.:

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...

Cannot happen that way, you have explicitely cancel his changes to do that either by merging or committing on top of his own changes.

1. 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...

DVCS repositories should be considered as standalone code trees. Some of them support partial checkouts but this is definitively not the common way to work. So basically, you always have all the repository tree checkout locally. Given that, you can copy or move directories using dedicated commands.

1. 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...

Cannot happen, because of the separation between commits and revision publications.

Now for ClearCase

1. ClearCase can manage extraordinarily large codebases spread across several geographical locations.

This is the main perceived drawback of DVCS compared to Subversion for instance. For instance, KDE codebase was contained in a single svn repository. It's conversion to a single git repository was out of question. And in my mind did not make sense. DVCS repositories are good matches for software packages. Then you compose your workspace with a collection of repositories checked out at the right revision. Mercurial support for this is experimental, I think git has this for some times, I don't know what it's worth.

1. It can be integrated with version control and bug tracking databases.

Nothing prevent this. There is a bugzilla plugin for Mercurial for instance.

1. 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.

DVCS forces parallel lines of development to be merged all the time. But with the constraints you describe, the merges are trivial and usually handled automatically by whatever tool you use. What's nice is you always can review what's been merge before committing. Anyway, these tools favor a pull model which scales much better than the push one.

1. 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.

Commits are repository wide atomic snapshots. So yes for tags, and yes for any revision actually.

1. It does have problems with cache-coherency. Modifying files on machines other than the build machine may end up with stale files being linke

Re:No mention of ClearCase?

[wrook]

Git an Mercurial are fundamentally different from the others you mentioned. They are distributed version control systems. You are free to set up your own topologies and methods for synchronizing. The biggest disadvantage is in not being able to easily checkout partial trees. This affects your workflow. IMHO, it results in a better workflow since you are forced to decouple the release of separate projects. But I'm sure I would get some stiff arguments from some people on that point. (My main argument is that if the release is coupled, then everyone *needs* to have an updated version of the project. If they don't need to have an updated version of the project, then you should be thinking seriously about what version they *do* need)

Anyway, you may or may not like this way of doing things since it is quite different from what you are used to. But it's worth your time to check it out.

Re:No mention of ClearCase?

[ztransform]

Essentially everyone who knows anything about modern version control considers CVS obsolete.

Clarification: everyone who thinks they know everything about modern version control considers CVS obsolete.

CVS still has advantages, in my opinion:
- simple underlying storage structure that any administrator can understand
- ability to simply administratively repair obscene or damaging check ins (investigate the cvs admin -o command, few other version control systems can do this)
- simple file numbering scheme

At the end of the day your needs may be more complex (regular branching, regular directory moves, etc) but in some commercial situations simplicity and ease of administration can be valuable points (and I think often outweighs the perceived benefits of SVN).

As for Git with it's advanced learning curve of at least a week, sometimes you have not just programmers contributing to a project but front-end designers, template producers, who have never seen a version control system in their life. Subjecting them to Git can be both cruel and potentially uneconomic - particularly if they are all on short term contracts.

Re:No mention of ClearCase?

[7 digits]

Nope. Moving directories within a checked out repository and committing their content will commit them back from where they were checked out.

His "save overwrite stuff" issue is probably due to him loading a file in his editor, updating the underlying version, and saving the file. If he uses a shitty editor, he may overwrite the changes. If he blindly commit his changes, he may have manually reverted the file. I've seen this happen with careless developers. I don't consider this a deficiency of CVS, as he actively overwrote the file. I could do that with any version control system.

His last point is wrong, though. Maybe he had some script that did some forced commit.

Re:No mention of ClearCase?

[Anonymous Coward]

Almost all the problems you discuss is with "raw" (eg people who do not want to use tool as it should be)
All the issues you list does not happen with UCM
ps. creating a branch non trivial? um, ok - ct mkstream -in -c jeez - brainsurgery

Re:No mention of ClearCase?

[Anonymous Coward]

A Subversion repository using the FSFS backend is essentially the same as a CVS repository in the two related areas you listed, and the SVN administration tools are far superior to the CVS ones. These days you should consider Subversion the baseline I.e. the bare minimum you should be using. I mean come on, CVS doesn't even have atomic commits or changesets!

Re:No mention of ClearCase?

[ztransform]

SVN administration tools are far superior to the CVS ones.

Pray tell, how are the SVN administration tools far superior, if not somewhat inferior, to the CVS ones?

I mean come on, CVS doesn't even have atomic commits or changesets!

Agreed. Every file is an individual unit with no relation to any other (with the exception perhaps of shared tags).

Re:No mention of ClearCase?

[Ed Avis]

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.

I'm really surprised to hear that, since it goes against all my experience of CVS. If you try to check in a file that somebody else has modified in the meantime, you will be prompted to update and merge in their changes first. In any case, no work is ever lost because you can always go back to the previous revision.

Or are you saying that you and someone else are trying to hack on the same working copy (the same directory) at the same time? That's not a sensible way to use CVS. You should each check out your own working copy, and check in your changes to the central repository as you make them.

Re:No mention of ClearCase?

[stoicfaux]

I have 7 years of ClearCase experience from 3.0 to 6.0, followed by a couple years of Subversion. First, CVS is obsolete. Comparing ClearCase to CVS is like comparing Windows XP to Windows 3.1. You're better off comparing ClearCase to Subversion.

ClearCase can manage extraordinarily large codebases spread across several geographical locations.

No. You need Mulitsite, a rather expensive add-in, to make make ClearCase work across high latency networks. ClearCase is extremely sensitive to latency. Dynamic views fail as you get into the 100ms range. Snapshot views fail around 250ms ping times. Turns out that ClearCase is very chatty and likes to send lots of small packets back and forth. (This really impacts a Unix/Windows interop/Samba setup.)

It can be integrated with version control and bug tracking databases.

So can most modern version control systems. In the case of the ClearCase/ClearQuest integration, it's just a very fugly perl script being fired by a hook.

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.

Standard feature nowadays. However, ClearCase is much better at managing merges than Subversion. SVN is a downright embarrassment when it comes to merge tracking (and thus merging.)

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.

ClearCase labeling is sloooooooow. Labeling a few thousand files can take 15 minutes as it walks the tree and pulls in each object. With Subversion, I can tag thousands of files in under a second.

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.

Dynamic views are a great idea, but aren't that practical. Even moderate amounts of latency (100ms pings) will noticeably slow them down. On the Windows clients with dynamic views, I've seen Anti-Virus screw things up, I've seen malware break dynamic views, and dynamic views are just naturally slower which slows down developer builds. Long story short, dynamic views are good for Admins or for looking at the code base without having to download the entire thing. However, for day to day developer use, snapshot views are much faster and more stable. Unfortunately, ClearCase snapshot views are just horrific (clumsy and limited features) when compared to Subversion workspaces.

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.

Again, a standard feature of most modern tools, Subversion included.

Overall, ClearCase merging is great. However, just about every other ClearCase feature sounds nice on paper, but just doesn't pan out too well when you start using it. IMHO, if Subversion had the merge capabilities of ClearCase, it would be difficult to justify ever using ClearCase again.

Re:No mention of ClearCase?

[gillbates]

No. But it does not sound like a good practice to me. I want to test this kind of stuff before committing and publishing the changes. Now, there are builtin commands to merge or cherry pick changes.

I there's some misunderstanding going on here: in CC, one can build with a bugfix without committing changes back to the repository. That is, suppose file.c exists in two branches, A, and B. If there's a bugfix in branch A, I can build branch B with branch A's version without modifying the version in branch A. That way, I can test the bugfix in branch B before committing it to branch B. If it doesn't work out, I haven't modified branch B at all - in fact, while all this is going on, another CC developer can checkout and build branch B without the concern that the untested bugfix would introduce problems with the current release.

Re:No mention of ClearCase?

[Anonymous Coward]

I use clearcase everyday at work and subversion for my own personal stuff. I have also used Mercurial.

I find that clearcase is far superior to the others and can be used similarly to how they all work (except for the distributed version control systems local commits).

Creating branches in subversion is kludgy, forcing you to "copy" the files into another directory (probably in /branch) and merging is dicey, especially since you have to specify which particular revision number to merge from and to, clearcase does this for you and all you need to do is perform a findmerge (and run the resulting script when using command line commands -- the gui merges the changes in one step).

Clearcase is much cleaner and easier. You can create branches anytime to hold changes and later merge them to any other branch or the"trunk" or "main".

At work, using clearcase, every developer creates their own view/branch to work in for every project/bug fix and the resulting branches are then merged into an integration view/branch for testing and eventual deployment, with the developers then merging changes from the integration view/branch into their own, private, view/branch.

Re:No mention of ClearCase?

[tricorn]

CVS does not allow you to commit a file that is not the same revision as the one you checked out. That's one of the primary functions. You MUST do an update (merge committed changes to that file back into your working copy and take care of any conflicts) before you can commit it. What it doesn't enforce is that you've updated all the files in your working directory, so inter-file inconsistencies can still bite you.

The only real problem I had with CVS is the "magic revision" numbers for branches and no good support for easily tagging a release version - each file is independent, each has to be updated with the tag for a specific revision, it's easy to create branches that only cover some files, so easy to get inconsistent branch labels, etc. It also didn't have any mechanism (other than comments) for marking what was merged with what. I'd have preferred something where you could "freeze" a release by saving the file revision numbers for the release into a specific file, and also having a "branch" file that simply saved the branch point and current revision, rather than doing magic with RCS tags and revision numbers.

CVS is very good with the "vendor branch" concept, something SVN doesn't really do. It's really nice if you simply get updated releases from another project, but have local changes that you want to keep across those updates.

Another good thing about CVS is also a weakness if you're a stickler for "correctness", as the underlying file structure is just a bunch of RCS files; that means you can use RCS commands on the repository to fix things up and use RCS commands to get information.

Re:No mention of ClearCase?

[BitZtream]

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...

My CVS server/client just mark unchanged files as committed on the local (committers) side when someone commits an unchanged file, the server ignores it, theres nothing to commit, no diff to create, nothing it can add to the system so it doesn't do anything.

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...

The only thing I can really say here is ... duh? What did you expect it to do, magically know you wanted it to be treated differently even though you brought along all the files that tell it how to be treated? There changes weren't disappearing either, they were committed somewhere if you committed them.

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...

My CVS server says 'up to date check failed' and blocks the commit, what server are you using?

Are you sure you've been using CVS, it hasn't really changed in years. Perhaps you should stop using some shitty server. I prefer CVSNT myself, builtin support for encryption and kerberos, atomic commits, and pretty much everything useful that SVN has to offer as well as compatibility with the massive amount of CVS servers and clients out there.

As for your ClearCase comments, CVS is capable of pretty much everything you just said, it can integrate with bug databases, mine does just fine, my repository is only a few million lines in one location so I can't speak to that part. Two or more developers can work on the same file and the merge is automatic most of the time as well. With a tag I can always checkout the exact same code, which is why our software has its build tag embedded in its resources. I've never heard of CVS having an issue with not having the correct checkout due to some cache error, but on that same not all our build machines do clobber builds, as we've only got a few million lines to build. ClearCase does appear to have the upper hand in merging to multiple branchs, but really it doesn't sound like you've used CVS much to give a very fair comparison.

Clearcase.

[Ungrounded Lightning]

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.)

Re:Clearcase.

[Ed Avis]

I haven't used ClearCase but I am wondering to what extent the features you mention can be provided using free revision control systems. Extremely lightweight branching is a standard feature of all modern systems; making a new branch for each feature or bugfix or experiment is pretty much standard practice with git. 'View spec' sounds cool. It could probably be implemented on top of git with a little bit of scripting (create a new branch, merge in the versions specified, then delete the branch when no longer needed). A make variant that reuses already-built objects sounds like ccache.

Re:Clearcase.

[Joutsa]

The 'view spec' thing is idiocy in its purest form. Consider the following case:

-You create a branch and a view that shows files in the branch on top of the trunk.
-You edit file A.
-Some other guy edits files A and B so that B won't work without the changes in A.
-Your branched version blocks the other guy's changes in A so you have broken source code until you merge.

The same thing happens even if you are both on same branch. In that case, the explicitly checked out file blocks any changes to tip or tagged revision.

Now think what this becomes when there are lots of files and several branches / tags in the mix. Yes, ClearCase tracks every single file separately and does not have any atomic operations, which makes things very interesting.

  With dynamic views, you see everyone else's changes immediately, which opens opportunities to all kinds of messes. Heck, if your software takes a while to compile, the source code can change a few times during the compile (remember, no atomic operations, so changes happen one file at a time). The dynamic view also needs constant access to server. The latest and greatest version I had to use just froze when the connection lost and crashed completely if the machine came back to net with different IP address.

Re:Clearcase.

[Ungrounded Lightning]

The 'view spec' thing is idiocy in its purest form.

It seems that way because you're using it wrong. (Like any powerful language it gives you enough rope to hang yourself if you tell it to do the wrong thing.)

-You create a branch and a view that shows files in the branch on top of the trunk.

And that was your error. You should only use "latest" for YOUR changes.

-You edit file A.
-Some other guy edits files A and B so that B won't work without the changes in A.
-Your branched version blocks the other guy's changes in A so you have broken source code until you merge.

Which is why you NEVER specify the bleeding edge of the trunk as the base of your view spec. You specify a release tag or trunk-(or-shared-branch)-as-of-date/time. Nothing in your view changes unless YOU change it.

When you've got your version working you merge in TWO steps:
  1) Merge the changes in the trunk (or whatever shared branch you're using) TO your branch. (Switch the trunk start time to the moment you start this step and merge the changes.) Build and run tests. (Repeat if this took long enough that the trunk thrashed.)
  2) Merge your changes TO the trunk and build-run again. (The build should be quick because, unless a LOT changed after you started your last iteration of 1) the objects should all-or-mostly be the ones you built in step 1).)

Even the build for the final merge test runs from a tagged or date/time version of the trunk. That way if somebody else checks in THEIR merge during your build you still get the version YOU merged. If your tests passed you can say "I left the trunk working as of (tag or date/time)". This becomes very important when the smoke tests take longer than the mean time between fix merges.

If you're going to switch to diverge/converge you have to switch all the way. Part of the POINT of diverge-converge is that you see NOBODY'S CHANGES BUT YOUR OWN until you have your part working and are ready to merge or you find you MUST incorporate somebody else's fix to get your stuff working.

Clearcase gives you the fine-grained control over what you "see" which makes this style a breeze.

Re:Clearcase.

[Ungrounded Lightning]

-You edit file A.
-Some other guy edits files A and B so that B won't work without the changes in A.
-Your branched version blocks the other guy's changes in A so you have broken source code until you merge.

Which is why you NEVER specify the bleeding edge of the trunk as the base of your view spec. You specify a release tag or trunk-(or-shared-branch)-as-of-date/time. Nothing in your view changes unless YOU change it.

By the way: One of the nice things about Clearcase is that, if you do make that error and get bit, you can fix your view AFTERWARD by editing one line in the view spec to back up the trunk view to a moment BEFORE the other guy checked in A and B. As I recall the Clearcase make understands that the actual source changed even if its time went BACKWARD and gets the dependencies right. (Try THAT with other version control systems.)

Re:Clearcase.

[Joutsa]

Part of the POINT of diverge-converge is that you see NOBODY'S CHANGES BUT YOUR OWN until you have your part working and are ready to merge or you find you MUST incorporate somebody else's fix to get your stuff working.

Wow, that was complex and error-prone. It is also exactly what distributed systems do easily. Heck, SVN can do that if you accept a worse merge support. For comparison, in any sane VCS you
  - create a branch
  - do your stuff
  - pull changes from trunk
  - push

Everything that you do with view specs happens automatically. No tricks with tags or dates (not that they work in CC, which still lacks atomic operations).

If you really want an expensive enterprise VCS that does what you describe, you should have a look at Synergy.

Re:Clearcase.

[Joutsa]

By the way: One of the nice things about Clearcase is that, if you do make that error and get bit, you can fix your view AFTERWARD by editing one line in the view spec to back up the trunk view to a moment BEFORE the other guy checked in A and B.

A Clearcase-specific way to fix a problem that exists only in Clearcase. A sane system would allow checking out the previous revision, which has been checked in as one changeset.

As I recall the Clearcase make understands that the actual source changed even if its time went BACKWARD and gets the dependencies right. (Try THAT with other version control systems.)

Moving file dates backwards is a bug, not a feature. As is getting married to a slightly nonstandard version of a primitive build tool. Anyway, at least SCons manages to compile things right, as it uses MD5 sums to detect changes and cache objects.

Bazaar

[Anonymous Coward]

How can no one have mentioned Bazaar http://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.

Corrupt working directories

[coryking]

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.

Savana - transactional workspaces on top of SVN

[SashaMan]

Friends of mine have open-sourced savana, http://savana.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.

Re:Savana - transactional workspaces on top of SVN

[trwww]

Why this instead of SVK?

Re:Savana - transactional workspaces on top of SVN

[JohnFluxx]

Why use this instead of git svn?

Re:Savana - transactional workspaces on top of SVN

[SashaMan]

They're pretty much unrelated. Savana doesn't aim to provide all of the functionality of git. What it DOES do is make it really easy to work "the right way" with SVN, with "the right way" defined as:

1. Every time I'm going to code a new feature/bug fix, I do it in a private branch.
2. I checkin normally on this branch.
3. When I'm ready to promote my changes, I first sync down any more recent changes from the trunk.
4. Optionally, I can have someone else look at my branch to do a code read.
5. I promote (merge my changes back to trunk) and drop my private branch.

It's currently possible to work like this now with subversion, but it's pretty ugly and a pain requiring long commands, and developers generally don't like it because it is such a pain to set up the private branches and merge them, so they end up just doing everything in trunk. Savana is essentially just syntactic sugar on top of (potentially multiple) underlying uglier svn commands. Savana aims to make it easy to set up and merge private branches, lowering developer resistance to using them.

Re:Savana - transactional workspaces on top of SVN

[JohnFluxx]

Given your description, it sounds almost exactly like git svn, except that git svn lets you do all of that locally.

1. Every time I'm going to code a new feature/bug fix, I do it on my own machine first.
2. I check in normally on this local 'branch'.
3. When I'm ready to promote my changes, I first sync down any more recent changes from the trunk.
4. Optionally, I can have someone else look at my branch to do a code read.
5. I 'dcommit' (merge my changes back to trunk).

with additionally

6. I can trivially reorder, squash and edit commits.
7. I can do all of this coding/changing offline.
8. All operations becomes blindingly fast - git log etc is near instant, without hitting the server

etc.

Bad writeup

[aevans]

Git and Mercurial aren't more popular than Subversion. Not by a long shot.

Am I the only one here using GNU Arch?

[Anonymous Coward]

I happen to like arch quite a bit, it does what I need and is simple to use.

Re:I'd suggest Git

[hysterion]

Surely IDE devs and bugtracker teams could build a decent abstraction layer so that any DVCS would work just fine with them.

Meet DVC...

Just one bit of advice

[MarkH]

Ensuring everyone in project is using same one is more important than which one is chosen.

If you can use the same one for a whole company even better

Re:Just one bit of advice

[JohnFluxx]

That can backfire. I worked at a large company where they did that. The result is that the whole company still uses RCS. Noone can upgrade because that would break the company policy of everyone using the same thing. And they can't all upgrade at the same time because it's a large company and everyone has different deadlines.

Nobody ever mentions binary files

[Terazilla]

I work at a game company, and the majority of what's in version control is either binary or (effectively) unmergable. I know this is relatively unusual when it comes to software development, but this fact alone gives me a lot of pause when thinking about whether something like Git would be a good idea compared to SVN, Perforce, etc -- discovering conflicts immediately is vital in this sort of scenario. Mentions of things like six-second merges makes me believe they can't possibly be testing with a repository of any significant size (tens of gigs, at least). How well does something like git handle this scenario?

Re:Nobody ever mentions binary files

[JohnFluxx]

git doesn't work well in that sort of scenario.

Where I work, the artists use SVN and the developers use Git.

Justin Case

[Cod33]

http://thedailywtf.com/Articles/The-Source-Control-Shingle.aspx

+1 Informative

[loshwomp]

Please mod parent informative, because it absolutely is.

Who says G*t is more popular than SVN?

[Qbertino]

Last time I checked Subversion was the current prime choice for VC Systems, for various reasons. Widespread availability of tools being the most prominent. Could it be that the summary is bullshitting on this issue? I think so.

VSS wins

[hesaigo999ca]

I hate to say an M$ product wins, but for me and my team(s), I would not go without. Of all the M$ products I have worked with, this has to be one of the best "Can't do without" apps out there. It is very user friendly and easy to use, but the only 2 bad things, the merge is not very good, so I use my manual comparison app to then do the updates....and the SQL to VSS backup is not what I expect, so again I have to manually write scripts to keep my dbs backed up (stor procs, tables,views etc..)

Re:VSS wins

[BitZtream]

So basically, you've never used a versioning system that didn't suck? MS doesn't even use VSS because it sucks that bad, for a long time they stopped even developing for it at all because they were trying to kill it off. Does it do anything well? The gui isn't any better than say WinCVS, its integration with Visual Studio is only as good as CVS/Subversion, not better. You're trolling, right?

Re:VSS wins

[hesaigo999ca]

You know, when we talk about using products, this is where you separate the men from the children,
and gotta tell, you are looking pretty small and immature right now.
1) VSS is the MAIN M$ product in use for code/file repository, as it has the biggest market share
for this domain.
2) When you say it does not do anything well, if you are trying to keep your windows clean, nope not the product for you. Trying to keep a good handle on what version of an app you are at, and branching off to select the next builds tasks for code development. It does exactly what it was designed for.
3)M$ does not even use its own product.... ummm... where is your proof dude, I know the internet is full of bullsh*t and I gotta say it stinks right now.
4)As for the cons of this app, version 6.0 that shipped with vb6.0 was the let down in terms of communication within a cross state domain. Problems with connectivity were apparent, and many people used a different client to access the VSS db because of the lag....
however, it always depends how you set up your projects too, if you have a solution/group that has say 20 projects inside and you want to always load all the projects each time...there is a trade to be had, however, just referencing those dlls , and seperating the dev. into projects and smaller solutions to avoid loading such a big project, helps improve VSS performance considerably as far as connectivity goes. Remember, if you have to work in a project to fix a few little bugs, and tweak the design, you dont need to load all the underlying dlls too, so branch off the project from the main solution and work just on that... speed is of the essence.

Re:VSS wins

[Anonymous Coward]

VSS is the MAIN M$ product in use for code/file repository, as it has the biggest market share for this domain.

ummm... where is your proof dude, I know the internet is full of bullsh*t and I gotta say it stinks right now.

If VSS is so wonderful, why did Microsoft bother to develop TFS?

My bet is you're a troll. What other breed uses "M$" (like a 15-year-old Linux fanboy) while simultaneously spouting BS about a product that is universally despised by many of the most vocal Microsoft advocates on the Internet?

bazaar the lack of mentioning bazaar

[Anonymous Coward]

Came across it recently and found it to be a little more intuitive to use than mercurial and git. Am I alone? Thoughts on it......

Re:Your official guide to the Jigaboo presidency

[Anonymous Coward]

Niggers hate working, so they love unemployment (and unemployment benefits). That's all you need to know about the Obama presidency.

If git is so good...

[larry bagina]

I use git to follow a couple projects (from github). (This is on debian (lenny) with debian's git binaries.) I don't touch the local code myself, just do occasional git pulls.

git pull consistently gives me problems like:

error: bad index file sha1 signature
fatal: index file corrupt
remote: Counting objects: 146, done.
remote: Compressing objects: 100% (92/92), done.
remote: Total 124 (delta 50), reused 72 (delta 15)
Receiving objects: 100% (124/124), 566.08 KiB | 501 KiB/s, done.
fatal: failed to read delta base object at 337995 from .git/objects/pack/pack-969e098f674ac9f6eac22f9dca0c61bf3aca615a.pack
fatal: index-pack failed

Why?

Re:If git is so good...

[hasdikarlsam]

Something is rotten, and git noticed it. There is file corruption.

I've seen that message exactly once myself, and the disk I saw it on died a week afterwards. You might want to consider replacing it.

the revision control system to NOT use

[Anonymous Coward]

Serena Dimensions sucks donkey balls. I would rather use plain old RCS than that piece of crap.

Check out Jazz from IBM Rational

[sv33]

If you haven't already.. please check out jazz.net and Jazz platform from IBM Rational. Yes the folks who brought you Clearcase has a whole new collaborative platform for version control and more. Agile developers really like Rational Team Concert