6 ms·

Martin Fowler's unscientific agglomeration of opinion on version control tools

62 points by adam-_- 17y ago

adam-_- 17y ago
If you can't be bothered to read the whole article, he recommends (based on anecdotal evidence) subversion, git and mercurial.
keefe 17y ago
"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...
- j_baker 17y ago
  Notice he said that svn is a good choice. Not necessarily the best choice though.
  - keefe 17y ago
    True enough, I just feel like scm and ci are relatively orthogonal issues
- easp 17y ago
  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.
  - keefe 17y ago
    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.
ThinkWriteMute 17y ago
I'm waiting for someone "popular" to realize how awesome Fossil is. Subv, Git, and Merc can all blow me.
- gthank 17y ago
  Doesn't Zed count as "popular"? He's been singing the praises of Fossil for a while now.
  - ThinkWriteMute 17y ago
    Yeah, I was there when he hopped on, but very few HN people would actually listen to him (sadly).
    - prodigal_erik 17y ago
      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)
- doki_pen 17y ago
  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.
- locopati 17y ago
  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.
- mikebo 17y ago
  What does fossil do that git or hg don't? I'd love to hear some real world examples.
jmount 17y ago
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.
mbrubeck 17y ago
"I used to hear people say good things about Perforce, but now the feeling seems to be that it doesn't have compelling advantages over Subversion, let alone the DVCSs." 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.
- btilly 17y ago
  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.
  - snprbob86 17y ago
    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 http://news.ycombinator.com/item?id=659251
  - yason 17y ago
    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.
    - 17y ago
Quarrelsome 17y ago
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.
- kogir 17y ago
  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.
  - gruntruk 17y ago
    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.
- mattmcknight 17y ago
  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.
- nobbynutz 17y ago
  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...
  - 17y ago
crs 17y ago
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.
InclinedPlane 17y ago
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.
nocman 17y ago
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.

62 points by adam-_- 17y ago

If you can't be bothered to read the whole article, he recommends (based on anecdotal evidence) subversion, git and mercurial.

keefe 17y ago

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

j_baker 17y ago
Notice he said that svn is a good choice. Not necessarily the best choice though.
- keefe 17y ago
  True enough, I just feel like scm and ci are relatively orthogonal issues
easp 17y ago
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.
- keefe 17y ago
  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.

ThinkWriteMute 17y ago

I'm waiting for someone "popular" to realize how awesome Fossil is. Subv, Git, and Merc can all blow me.

gthank 17y ago
Doesn't Zed count as "popular"? He's been singing the praises of Fossil for a while now.
- ThinkWriteMute 17y ago
  Yeah, I was there when he hopped on, but very few HN people would actually listen to him (sadly).
  - prodigal_erik 17y ago
    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)
doki_pen 17y ago
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.
locopati 17y ago
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.
mikebo 17y ago
What does fossil do that git or hg don't? I'd love to hear some real world examples.

jmount 17y ago

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.

mbrubeck 17y ago

"I used to hear people say good things about Perforce, but now the feeling seems to be that it doesn't have compelling advantages over Subversion, let alone the DVCSs." 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.

btilly 17y ago
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.
- snprbob86 17y ago
  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 http://news.ycombinator.com/item?id=659251
- yason 17y ago
  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.
  - 17y ago

Quarrelsome 17y ago

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.

kogir 17y ago
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.
- gruntruk 17y ago
  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.
mattmcknight 17y ago
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.
nobbynutz 17y ago
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...
- 17y ago

crs 17y ago

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.

InclinedPlane 17y ago

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.

nocman 17y ago

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.