One VCS to rule them all...

Having gone through different VCSs of varying (mostly poor) quality and cost over the span of my career, I am glad to see that that a de facto standard seems to be being settled on. Git is quite good, far better than any other solution I have used on a day-to-day basis. (No disrespect intended to Mercurial, etc.)

While having a breadth of technological solutions to problems is frequently a benefit, I'm not sure source code control falls into this category. This is an area ripe for de facto standardization. Developers should be able to go to a new job without having to relearn the intricacies of MKS, SVN, etc.

While I'm all for abandoning old and often awful VCSs, I do think there's room for some diversity. Git's not really my thing, and I'm happy to be able to use an alternative. Most DVCSs work in very similar ways, and for standard use, I don't think there is a huge learning curve for someone switching between git and mercurial, for instance. Some other tools have their own benefits, like fossil with its nice integrated web project management features. All in all, I'd be quite sad to see only git everywhere.

Obviously no one should be forcing you to use what you don't like. But I don't quite understand that reasoning. Except for rare circumstances, SCM use isn't a "personal" activity. It's not about what you pick for yourself, it's about what everyone collectively chooses to use for collaboration.

And in that sense, there are really high costs to variety. Imagine a world where you need to be fluent not just in whichever two of RCS/CVS/subversion/git are currently en vogue, but also mercurial, SCCS, bitkeeper, Perforce, ClearCase, etc... That's a mess.

So sure, git might not be "your thing", but I strongly suspect you'd still prefer a git-only world to one where every project you want to tinker with uses a different SCM.

By "I don't like git", I mostly meant that git's not my favourite VCS, not that I'd refuse to use it or actively advocate against it or anything. I'll always use what's most convenient for the team as a whole. The point was that when I have a choice, I'd rather use mercurial than git. But really, those two are really close. There's even a plugin that lets you use interact with git repos from mercurial.

And of course I can only agree with your last sentence, a bit of standardization is a good thing.

> While I'm all for abandoning old and often awful VCSs, I do think there's room for some diversity.

So do I. I just think that it will be nice should there come a day where knowing git will allow you to deal with the majority of the positions out there. I do not believe git is a 100% fit for all organizations. I do, however, believe git is flexible enough to be a fit for, say, 80-90% of them.

I think git will become a de facto standard. Like all such things, though, there will be alternatives available and in active use.

I see your point, and I'd much rather see git become a standard rather than a Visual Source Safe clone.

At work I chose (yeah, there was no VCS in use before that) mercurial mainly because we're a small .NET shop, and a nice GUI like TortoiseHg is a big selling point when you're trying to encourage people to use such a tool. There are actually lots of developers who just <i>hate</i> using a CLI. And I don't know how things have evolved, but git was not known to be very windows-friendly two years ago, even apart from the GUI thing.

How is TortioseGIT deficient compared to TortoiseHg? I would think at this point, they are sort of equivalent, but I don't have experience with Mercurial.

Well last I checked (which is now quite a while back) it seemed far less polished and stable. However I'd probably have to try it again, according to what I can see on the project's page it seems to have improved a lot.

From my recent experience (past month or so), TortoiseHG is definitely more polished than TortoiseGit. The thing I miss the most is the "Workbench", a single window that contains everything you'd need to do (commit, view history, sync, etc).

Right on Microsoft! It's great to see a software powerhouse able to turn its entire outlook about to keep it's users coming back. Between the ever wonderful Visual Studio IDE, and MS's new-found appreciation for how open-source can enhance it's position, it's a good time to be a .Net dev.

Totally agree. If they threw their weight behind Mono C# would be my language of choice for everything.

I agree, Visual Studio and C# are great tools, and complemented by open source tools like Git, libraries and extensions like SpecFlow, it makes a pretty compelling development environment.

Completely true, but Github still beats Codeplex by parsecs.

I guess the great thing about DVCS is that you can have your 'latest' code available with full history at codeplex and github if you want to. And if one goes out of business, stops supporting Git or whatever you just push to bitbucket, somewhere else or self-host.

They do different things. Github excels when it comes to community & source management, but doesn't really do anything to help you set up a project home page, manage official releases, or anything like that. Codeplex is more of a Sourceforge-style "one stop project hosting" site.

They do have a way of setting up project pages: http://pages.github.com/

And each project has a download list which can contain official releases, or you can just link to a tag as a zip download. Github also has a pretty decent issue tracker and wiki.

I'm not so sure that's a difference in focus as it is evidence for holes github has to fill. They're moving in that direction already with the project wikis, which I think are great.

I too would really like to see things like mailing lists, forums, and a bug tracker that doesn't suck (seriously guys: you couldn't just reskin bugzilla?). But I suspect github agrees with that, and will get there eventually.

I wonder how much effort it took you to ignore all the websites which are directly fed from GitHub. :-)

Now if we could just get them to step away from TFS...

I love DVCS and used Mercurial for a year exclusively, but one thing that TFS does really really well is lifecycle and issue management. The way you can put a project plan (essentially) into it as a collection of work items and then track burndown/earned-value as code checkins are occurring is really awesome. My stand-by joke is that TFS would be an awesome lifecycle management tool if only it had a good version control product. When you work in a large enterprise (read: bureaucratic) where you have to satisfy a small army of project managers who are watching the dollars tick by, TFS has many pros worth considering.

I don't know TFS, but isn't it possible to just use the ALM tools for project management and keep using mercurial, git, svn or whatever else you prefer as VCS? Is the link between the two really required?

It's not required, but when you check code into TFS, you can associate it to a backlog task in the UI. You'd miss that.

Correct. I used Mercurial with Redmine and you could tag your checkins with special text "closes #39" for example. It's quite a bit more cumbersome than having a filtered query alongside your checkin dialog that you can just tick a checkbox. Especially when your development team has a, let's say, mix of skill levels.

Most project management tools support this feature these days (JIRA, FogBugz). Association between commits and ticket/bugs/features/etc.

I believe some of them even gone further by providing a RELEASE.txt type of output if you follow their preferred way of handling releases/versioning/milestone.

Indeed. In the meantime, check out Git-Tfs (http://git-tfs.com)

I feel your pain.