Martin Fowler's unscientific agglomeration of opinion on version control tools(martinfowler.com)
martinfowler.com
Martin Fowler's unscientific agglomeration of opinion on version control tools
http://martinfowler.com/bliki/VersionControlTools.html
9 comments
Other than that, Perforce is junk. Here's a nice feature. To decide what files to commit, you edit the boilerplate "p4 submit" generates in $EDITOR. Except if there is a problem exec-ing $EDITOR, p4 just decides to commit all your changes with no message. p4 may be good server-side, but the clients are junk, and I wouldn't trust them with anything important. Like with Subversion, if I ever have to do something complicated, I always make a "cp -a" backup first.
Git may be "hard to use", but at least it doesn't shred my work for no reason.
Git may be "hard to use", but at least it doesn't shred my work for no reason.
The biggest advantage that Perforce has is better performance with large code bases than subversion, git, or mercurial.
My guess is that most of us don't work with large and active enough code bases for this to matter. But if you do, consider Perforce.
My guess is that most of us don't work with large and active enough code bases for this to matter. But if you do, consider Perforce.
As someone who has worked on several large code bases with Perforce, Source Depot (Microsoft's Perforce fork) and TFS (Microsoft's Perforce rewrite/productization), I honestly think that the ability to handle really large code bases is actually more of a curse than anything else. See my old post about version control scaling up vs scaling out here: http://news.ycombinator.com/item?id=659251
These said large code bases are usually much less of code and much more of binaries, test images or media streams, complete devtool suites, arch compilers, and almost anything that generally would require less version control and more availability control.
In other words, stuff you would actually want to live on a network drive or some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to Perforce, it will happen.
In other words, stuff you would actually want to live on a network drive or some other sharing mechanism. But if it's easy enough to shove 10 gigabytes to Perforce, it will happen.
For some of these things, sure. But if you put your compiler tools, external binary references, etc. on some share somewhere outside of version control you will find that when you go to create a patch for some older release you are well and truly effed. Being able to sync and build with nothing but a bare OS and the relevant source is a HUGE benefit when you have to support older releases on the level that, say, Microsoft does.
It is still the wrong solution.
Disk space is cheap and what you really want is access to cumulated, unchanged old versions -- not version control: you generally don't diff or merge between compilers or test images.
Instead, you can store builds of each and every gcc version you've ever used on a network disk with very little money and then properly use the version control system to have the different revisions of the source code point to the correct set of tools and resources.
It's like a persistent data storage with good accessibility and no delete command. This is the only real reason why people abuse their version control system with huge binaries and it's the only reason I can think of. I shall bow to anyone who has the guts to refuse to abuse and do it properly instead.
Disk space is cheap and what you really want is access to cumulated, unchanged old versions -- not version control: you generally don't diff or merge between compilers or test images.
Instead, you can store builds of each and every gcc version you've ever used on a network disk with very little money and then properly use the version control system to have the different revisions of the source code point to the correct set of tools and resources.
It's like a persistent data storage with good accessibility and no delete command. This is the only real reason why people abuse their version control system with huge binaries and it's the only reason I can think of. I shall bow to anyone who has the guts to refuse to abuse and do it properly instead.
Given the known bugs [1] that reflect your svn merging experience, it seems the majority of svn users, myself admittedly included, just never do reflective merging in svn or else there would be more of a fuss over it.
As a good illustration for others of what you're talking about, the bug report points to this picture [2] in which commit 17 to trunk is what causes svn problems.
[1]: http://subversion.tigris.org/issues/show_bug.cgi?id=2897
[2]: http://www.open.collab.net/branding/images/projects/merge/re...
As a good illustration for others of what you're talking about, the bug report points to this picture [2] in which commit 17 to trunk is what causes svn problems.
[1]: http://subversion.tigris.org/issues/show_bug.cgi?id=2897
[2]: http://www.open.collab.net/branding/images/projects/merge/re...
I would suggest a different checklist to pick version control systems. Point one my list would be: "does the system preserve or damage your original?" CVS and SVN both fail on this by writing dot files in each and every directory of what you are trying to manage (breaks some non-compiler applications)- so I would lean more to Git, Mercurial and BZR.
TFS is not that bad... the issue is that you have to pay through the teeth to have it and it is not that good.
When it comes out of the box as a bag of bits that you're going to have to configure, hack and code for hours to get what you want you sometimes wonder why you didn't just go SVN + Cruise Control.
For the record, I just wanted my test pass/fails to be emailed to us in a NUnit gui way (red + green). Maybe i'm stupid but that took way too long for a tool that costs so much.
When it comes out of the box as a bag of bits that you're going to have to configure, hack and code for hours to get what you want you sometimes wonder why you didn't just go SVN + Cruise Control.
For the record, I just wanted my test pass/fails to be emailed to us in a NUnit gui way (red + green). Maybe i'm stupid but that took way too long for a tool that costs so much.
TFS has some redeeming qualities when looked at as part of a holistic software development platform - bug tracking, work items ect. but purely as a source control system it is bad.
Day to day experience is just friction, friction, friction.
And guess what keeping source control and your IDE seperate is actually a good idea. Also why do I care that Alex down the hall has opened a file - what am I supposed to do with that information...
Day to day experience is just friction, friction, friction.
And guess what keeping source control and your IDE seperate is actually a good idea. Also why do I care that Alex down the hall has opened a file - what am I supposed to do with that information...
"And guess what keeping source control and your IDE seperate is actually a good idea. "
Too true. Killing time watching your IDE lock up is not fun. Nor is the fact that _some_ IT departments still haven't performed the upgrade from TFS 2005 unservicepacked
.. ..
cries
Too true. Killing time watching your IDE lock up is not fun. Nor is the fact that _some_ IT departments still haven't performed the upgrade from TFS 2005 unservicepacked
.. ..
cries
The fact that you need a licensed product everywhere you want to check out the code, including the server, was a huge PITA for us. VisualSvn did the trick for us at the time.
TFS is that bad. Offline access is non-existent. You can't even record a file addition without a connection to the server. I checked it out at Loopt, but for all it offered, I found SVN + Hudson to do everything we needed better.
Yeah, my experience having to swap to TFS from SVN was awful given the completely connected nature of it. The only way to make it bearable was by adding 3rd party add-ons that should of been there from V1 already.
If you can't be bothered to read the whole article, he recommends (based on anecdotal evidence) subversion, git and mercurial.
Wow, the article says "Historically git worked poorly on Windows, poorly enough that we'd not suggest it. This has now changed, providing you run it using msysgit and not cygwin.". I find that interesting, and have 2 comments:
1) friends don't let friends use Windows without Cygwin :-D
2) I've been using git under Cygwin on Windows XP since mid 2007, and have never thought that it worked poorly. In fact I would say that it has always worked beautifully.
Perhaps the problem(s) with Cygwin git only rear their ugly heads on multi-developer projects. My experience has all been on single-developer projects.
1) friends don't let friends use Windows without Cygwin :-D
2) I've been using git under Cygwin on Windows XP since mid 2007, and have never thought that it worked poorly. In fact I would say that it has always worked beautifully.
Perhaps the problem(s) with Cygwin git only rear their ugly heads on multi-developer projects. My experience has all been on single-developer projects.
When I first started using clearcase I hated it. Now many years later, I really appreciate the power it brings to the table. Sure it has negatives just like all vc tools too, but the easy branching, dynamic vs snapshot views, automatic merging, the ability to merge directly from a fellow developers views, etc. has really made my team more productive. However I will say that it takes considerably more expertise to setup and maintain that something like svn or git. So there is the added expense of having full time clearcase admins.
"Subversion encourages a simple central repository model, discouraging large scale branching. In an environment that's using Continuous Integration, which is how most of my friends like to work, that model fits reasonably well. As a result Subversion is a good choice for most environments."
...using continuum you can just plug in a POM with a git connector and no trouble with CI and git...
...using continuum you can just plug in a POM with a git connector and no trouble with CI and git...
I think you missed the point, which is that Subversion discourages branching, which is fine, because most of the people he knows do CI. His point is not that you can't do CI with GIT.
My point was that I don't see how the two are related - if you're building off a branch you can still write a pom that builds your particular branch and the rest of the trunk code and gives you all the benefits of CI.
This review (at least it's admittedly unscientific) suffers from a common problem of many critiques of software development practices: a lack of appreciation for diversity. Software development spans a much wider range of conditions than almost any other human activity, scaling from a lone developer working part-time on a personal project up to teams of thousands of devs and testers working on billion dollar or perhaps even life-critical software.
Software development efforts can span 6 or more orders of magnitude difference, and can differ in character enormously (such as between a scheduled release cycle of unpatchable, life-critical software vs. a constantly updated web site). Yet despite this huge diversity, most commentators insist on ignoring it and giving blanket advice as if it were equally applicable to every development effort in the history of the Universe.
The various drawbacks and benefits of different source control tools will matter differently to teams of different scales and processes. For some teams SVN may make sense, for some it may not be even remotely feasible. I've heard of teams that could not use git because of scaling issues (shocking as that may sound).
It's hard to take advice seriously that doesn't acknowledge these issues. It's no different than someone talking about web infrastructure and saying that the best solution is php/apache and mysql running on two separate servers. That may be a fine solution, but it's overkill for some scenarios and unsuitable for a lot of other scenarios. Sometimes you need a thousand servers, sometimes you only need a single 128mb ram VPS, sometimes you need scala or erlang, sometimes you don't need anything more than static html, sometimes you need a REST backend, sometimes you don't, sometimes you need nosql, sometimes you don't. What works for amazon.com may not be applicable to a personal vanity page or to twitter or google or paypal.
Software development efforts can span 6 or more orders of magnitude difference, and can differ in character enormously (such as between a scheduled release cycle of unpatchable, life-critical software vs. a constantly updated web site). Yet despite this huge diversity, most commentators insist on ignoring it and giving blanket advice as if it were equally applicable to every development effort in the history of the Universe.
The various drawbacks and benefits of different source control tools will matter differently to teams of different scales and processes. For some teams SVN may make sense, for some it may not be even remotely feasible. I've heard of teams that could not use git because of scaling issues (shocking as that may sound).
It's hard to take advice seriously that doesn't acknowledge these issues. It's no different than someone talking about web infrastructure and saying that the best solution is php/apache and mysql running on two separate servers. That may be a fine solution, but it's overkill for some scenarios and unsuitable for a lot of other scenarios. Sometimes you need a thousand servers, sometimes you only need a single 128mb ram VPS, sometimes you need scala or erlang, sometimes you don't need anything more than static html, sometimes you need a REST backend, sometimes you don't, sometimes you need nosql, sometimes you don't. What works for amazon.com may not be applicable to a personal vanity page or to twitter or google or paypal.
I'm waiting for someone "popular" to realize how awesome Fossil is. Subv, Git, and Merc can all blow me.
Tool support is another factor in uptake. If my IDE and my continuous integration server don't support the system, it's not even on my radar.
He mentions mind-share as a factor. It is compelling that I can go in #git on freenode and have any questions I have answered promptly and completely.
Doesn't Zed count as "popular"? He's been singing the praises of Fossil for a while now.
Yeah, I was there when he hopped on, but very few HN people would actually listen to him (sadly).
I take source control advice from people who are bigger freaks about robustness than I am. But I will always remember Zed as the guy who took a straw poll (of English speakers!) about whether it would be okay to drop email on the floor if his server didn't understand its text encoding. So, no.
(edit: your downvote wasn't me)
(edit: your downvote wasn't me)
What does fossil do that git or hg don't? I'd love to hear some real world examples.
It's a one file install. You can easily run it behind firewalls. It has built-in wiki and issue tracking. You can run it from a jailed host; it requires no access to apache config, it has its own server. You can give users accounts on it. You can run it in autosync mode, where everyone's changes are sync'd through a central repo, or you can use manual merge for disconnected use. It uses the battle-tested sqlite as its transactional local store. It is designed to optimize the author's preferred workflow, so if you agree with him in principle, you'll like its ui. Like, e.g., git, it uses SHAs for "artifact" tracking; the sqlite db can be rebuilt from the canonical artifacts. I haven't looked for any comparisons, but it's extremely efficient space- and bandwidth-wise. It's written in SQL, which is semantically efficient, so it's easy to understand how it works.
It adds bug tracking and project wiki to your DVCS.
Perforce still has better support for branches than Subversion does - in particular, it has robust support for repeated merges between branches. Subversion 1.5 added "merge tracking" which is supposed to address this problem, but in my real-world use Subversion still failed relatively often at repeated merges and the recovery process is tedious and annoying.
On that particular project we ended up switching to git, but I would definitely choose p4 over svn for use cases (like very very large repositories) where they are both better than git or hg.