17 ms·

Abandon your DVCS and return to sanity

331 points by drostie 12y ago

grabcocque 12y ago
Github link to his proof-of-concept centralised VCS that doesn't suck..? That's what I thought.
- xtrumanx 12y ago
  Do you think its unacceptable to criticize the best product in a category because there's nothing better than it? His point was DVCSs like Git and Mercurial may have been an improvement in lots of aspects of version control system but they have taken some steps backwards as well. I thought he was kidding about the crazy juice...
- terrywilcox 12y ago
  Why would anybody writing a new VCS use Github to host it? Wouldn't it make more sense to use the new VCS itself. You know, eat your own dogfood?
  - jusio 12y ago
    Not everyone is using GitHub for source hosting, there quite a few companies, which use internally some other VCS (like Perforce) and publish the sources on GitHub.
- ngoldbaum 12y ago
  Facebook and google are working on turning mercurial into such a VCS, although it will still be a DVCS allowing fully local commits (albeit without storing the full history on all clients). Take a look at the remotefilelog extension.
jimktrains2 12y ago
> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging. No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing. > Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. Well lucky him for only being able to code when he has a nice connection, not all of us do. Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?
- grabcocque 12y ago
  I fell in love with git because it's FAST. And it's fast because it's distributed.
  - bryanlarsen 12y ago
    Have you ever used Perforce?
    - jimktrains2 12y ago
      You mean that proprietary code? No, I avoid non F/OSS at all costs.
      - politician 12y ago
        Wherein it is pointed out that Hacker News is proprietary software.
        jcl 12y ago
        Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
        squeaky-clean 12y ago
        Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
        vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
        jimktrains2 12y ago
joosters 12y ago
I think the author is just misunderstanding most people's use of version control. We learn a tool well, so we continue to use it in situations where it might not be the best for the job in hand, or might be over-engineered for the purpose. Git falls into this use case a lot because once you understand how to use it, why not continue to use it, even if the project doesn't really need distributed version control. It's a waste of time to learn a new system. Personally I've never even bothered to learn git. I used to use Perforce at work, now I use it for my own projects. It does the job well, why switch?
iand675 12y ago
Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let's not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell. Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky. Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. Other objections to this article: * Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) * The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal. I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.
- masklinn 12y ago
  > The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. And for a third, it opens options which are not available without that. Annotating or bisecting with server round-trips every time is not really an option.
  - CHY872 12y ago
    I disagree - I've done bisects on very large codebases, and they take a while (5-10 seconds for a checkout, perhaps). This is all immaterial compared to the time to recompile the code (possibly a minute or two to get everything recompiled (a Java project)).
    - jsight 12y ago
pron 12y ago
Note that the author of the article doesn't advocate forgoing local commits, but something like Facebook's work on a semi-distributed Mercurial, which allows local commits without cloning the entire history to each client. Here's the relevant section from the linked post[1]: But what if the central Mercurial server goes down? A big benefit of distributed source control is the ability to work without interacting with the server. The remotefilelog extension intelligently caches the file revisions needed for your local commits so you can checkout, rebase, and commit to any of your existing bookmarks without needing to access the server. Since we still download all of the commit metadata, operations that don't require file contents (such as log) are completely local as well. [1] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
baldfat 12y ago
I use GIT for backup. the D allows this to happen and if I goof I can always go back to where I was. Always worth it for a single workflow.
jlarocco 12y ago
> Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. Or if you're a Kiln customer, and their site is taking 4 minutes to load a page, assuming it's not just down... Sorry, couldn't resist... Seriously, though, I don't see where the author is going with his rant. It doesn't say much, and almost seems like a snide jab at Git and GitHub. None of his points are very good. Yeah, it doesn't take a DVCS to treat the whole repo as a unit. But right now they're the only ones who do. A hypothetical patch to SVN doesn't help me much. Also, I know from experience that SVN is horrible at binary files, and especially horrible at large binary files. I'm not saying Git and Mercurial are great, but they're no worse than SVN. The entire section about the amount of books and documentation is just silly. There was a LOT more subversion info around than "just the Red book". I owned two books, and I know we had a few different ones floating around the office, not to mention boatloads of tutorials and guides online. It's also funny how he makes fun of GitHub's git tutorial, but doesn't mention Kiln's Mercurial and Git tutorials. He also rips on GitHub's pull requests, but fails to mention that they work better than Kiln's. But it's great to see the founder of Kiln telling everybody not to use the technology his company is based on...
- Tobani 12y ago
  Interesting about kiln. My interpretation was: 1) Rant about a problem specific to you... 2) Provide no meaningful guidance or solution... (Except move back to SVN to solve a problem I don't have) 3) Make it to the top of Hacker News? 4) ??? 5) Profit?
  - netghost 12y ago
    Actually he does point folks towards the work being done with Mercurial to embrace the centralized + offline commits model. Facebook's apparently been building some good stuff around that.
nightski 12y ago
Are these complaints all against DVCS? It seems a lot of them if not all are just shortcomings of currently available offerings (git/mercurial) whereas the author is directing them at DVCS directly.
brockers 12y ago
The best part of the whole article was the line: >> "If you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard.
makmanalp 12y ago
> No, the only thing that a DVCS gets you, by definition, is that everyone gets a copy of the full offline history of the entire repository to do with as you please. > Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. > That’s fine for a centralized system. You only have one copy at any give point, so the amount of disk space you need is basically the size of the current (or target) version of the repository—not the whole thing. > This means that changing a file in a deep directory will require generating new trees for every directory up the chain—and, of course, that figuring out what changed in a given directory requires loading up all the trees going down the chain. Wondered why git blame runs slow as hell on big repos? Now you know. (is this even true? Git blame is slow because it digs through history) > Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. People will write books about anything because people will read books about anything. > Indeed, to listen to this, you would believe that open-source development was impossible, or at least absolutely horrible, before GitHub sprang into melodious existence. The pull request critique is so silly I'm not even going to try. ---- I really don't see how any of his critiques have to do with DVCS vs VCS. Literally none of them. This really is a Git rant. If you don't like Git, I guess that's fine. The problem with git is it's more building block than slick foolproof user tool, but some of us like it that way. Git is the first prominent example of someone thinking hard about the low-level theoretical implications of version control (the idea of the state of the entire repo as a changeset, the underlying data structures, etc), and then building a tool around it that works well. When I look at SVN, for example, it's not obvious what the hell we were even thinking - there was no theoretical framework, it was just the simplest thing that worked. And it didn't work well. Branches were more of a pain than a feature. So yeah, there's obviously room for improvement, but I don't even understand the complaint against DVCS in general here. edit: formatting edit2: or rather, it's about the current state of DVCSes, but I don't see how most of these would be made better by switching back to a centralized VCS and I'm not convinced that improving these are mutually exclusive with having a distributed version control system. I think there's come conflation of concepts going on here.
- eos_styx 12y ago
syntern 12y ago
I think that a combination works best, but it looks like not many do a central SVN + local git setup. Any reason for that? Do you have bad time with that or what? The central SVN is much better for tracking versions for release purposes, while the local git has all the benefits of working on one thing than switching to another. Any thoughts?
- syntern 12y ago
  Basically this: https://www.kernel.org/pub/software/scm/git/docs/git-svn.html https://www.kernel.org/pub/software/scm/git/docs/git-svn.htm... http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/ http://flavio.castelli.name/2007/09/04/howto_use_git_with_sv... http://andy.delcambre.com/2008/03/04/git-svn-workflow.html http://andy.delcambre.com/2008/03/04/git-svn-workflow.html
etep 12y ago
This: Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website.
- jimktrains2 12y ago
  You do know that there are many multiple SVN books out there in addition to the red book?
  - ams6110 12y ago
    But you don't really need them. The red book tells you pretty much all there is to know (I say that based on memory from years ago, the last time I used SVN. I liked SVN. It was easy to use, easy to understand, and did everything we needed for our project (a half a dozen developers all working in one office). It was such a breath of fresh air coming from our previous VCS (Visual SourceSafe).
    - jimktrains2 12y ago
      And you don't really _need_ a git book either. There is a lot of nice information on the git site and the man pages (even considering the man pages notoriety in not being consistent in terminology).
      - pwang 12y ago
        Which is why the nvie.com "git flow" (that everyone points to as the ideal branching model for git) is not actually on the git site? And as for git man pages... I have been hacking on Linux and complex codebases for 20+ years at this point but have never been so befuddled as I have been by the git man pages.
- ambrice 12y ago
  So, going by the number of books and tutorials metric, java is a much more complicated programming language than erlang? Have you seen how many books and tutorials java needs?
greggman 12y ago
svn isn't really a solution for binary files. It also requires workarounds. Sure it doesn't have the issue of every version of every blob but it still needs 2 versions of every blob. If you're on a game with terabytes of source data which is common for a AAA game 2x terabytes is not a win. It also doesn't help you manage collisions by locking every UNMERGABLE binary file so you know before you edit if someone else is or has already edited the file. I know you can set local options to make it lock the files but that feels more like a workaround.
- stsp 12y ago
  Binary files are by definition unmergeble with a diff3 algorithm implementation that uses text tokens separated by \n. Specific software to merge a binary file format can be used with virtually any version control system if available. You can set an svn:needs-lock property on binaries. It is not a local option, it applies to everyone using the repository. For extra convience, use svn:auto-props (acts recursively) to set it by default on new files which match a particular filename pattern (e.g. match on file name extension). http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config http://subversion.apache.org/docs/release-notes/1.8.html#rep... EDIT: That said, I agree that some types of binary files really have no place in SVN repositories. One example are release artifacts, as stored e.g. in Maven repositories.
huu 12y ago
I don't think the existence of more books for git as opposed to svn proves that it is more difficult. I think it's more a reflection of how popular/accessible git is, and publishing more books is a way for the market to address a bigger audience.
karmajunkie 12y ago
I had no idea there were so many repressed SVN-loving developers out there.
matthewmacleod 12y ago
Of all the problems we have as an industry, I'm convinced that version control is near the bottom of the list. Sure, 'DVCS' in the form of git or mercurial doesn't deal well with binary files, and has large repo sizes. If these are problems, you might be using the wrong tool. But that's fine; pretty much everybody should be using something like git or mercurial. They're flexible, relatively easy-to-use, and cover almost all use cases. If you need to store large frequently-changing binary blobs, then you are probably in a minority; there's nothing really wrong with git-annex for managing that content. But this whole thing we're seeing at the moment with people objecting to DVCS utterly mystifies me, as someone who went from CVS to SVN to git and has utterly no interest in going back.
balabaster 12y ago
Hahahaha love this. But I think all version control systems suck - not inherently, but because their usability is atrocious. I enjoy Git... well, perhaps enjoy is a strong word, perhaps what I really mean is I have Stockholm Syndrome. I've tried to go back to TFS, SVN and other centralized systems, but I'm too emotionally bonded to having my source control system with me, everywhere I go... Starbucks, Tim Hortons, the Train, sitting on the beach. But I don't delude myself into thinking this is anything more than emotional. I like having it there, it gives me comfort - and there is some convenience. I don't want to have to worry about "How do I undo all those changes from my last 10 commits and go back to where I started down this path?" Git gives me that nice fuzzy feeling of being able to play meaninglessly with my code until something takes form and if it comes to nothing, I can do git reset --hard 1f3c2047 and I'm right back to where I was before I went down this path of insanity...and if it takes a nice form, I can do git rebase -i and squash all my messy commits into a single commit with a single commit message. I didn't need to branch, I didn't need to clone, I didn't need to do anything crazy, I just fire up Bash and I'm done, no muss, no fuss, no having to be connected to the source control server, no dependence on anyone else... and if I did want to put that code aside, I can stash it or spin it onto another branch before coming back to my original branch and resetting back to a sane commit. It's nice having ultimate control. But having that amount of control has its drawbacks...you can't expect the ability to drive stick, but not have to learn how to use a clutch and gearshift.
hpaavola 12y ago
What are the (open source) centralized version control systems that do merging and branching like git?
zo1 12y ago
>"The actual reason is because GitHub let coders cleanly publish code portfolios, and GitHub happened to use Git as the underlying technology to enable that," Is this guy genuinely suggesting that people fell in "love" with distributed version control solely because of GitHub? I don't feel old enough to be telling this author to get off my lawn. I mean, GitHub is great and all, but it does not represent the sum whole of all the commits in this world. Granted, does anyone know the timelines of when DVCS took off (as opposed to launched)? Mercurial and Git were both released a good 3 years before GitHub was launched. Okay, I looked up more about DVCS. Wikipedia article's history section on it: History Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in enterprise settings in the 1990s and inspired BitKeeper (1998), one of the first open systems. BitKeeper went on to serve in the early development of the Linux kernel. First generation open-source DVCS systems include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others. When the publishers of BitKeeper decided in 2005 to restrict the program's licensing,[5] free alternatives Bazaar, Git, and Mercurial followed not long after.
- Zelphyr 12y ago
  I had the misfortune to have used Arch around 2005-2007. That was an excruciating experience. Updates that would take over an hour.
- vezzy-fnord 12y ago
  I think both of you are respectively overestimating and underestimating the significance of GitHub. Are there a lot of projects that use Git without a hosting intermediary because of genuine advantages? Yes, absolutely. Plenty of core infrastructure and applications, many of which significantly predate Git or GitHub. Is there a growing subculture of people who essentially equate Git with GitHub and end up completely subverting the "D" in DVCS, incurring unnecessary downtime and who pretend Git/GitHub are the be-all-end-all? Also yes, with circles such as those of HN being overrepresented with "GitHub is your resume" rhetoric and various startups or hip SaaS having GitHub be their single point of failure. Being the #1 software hosting site in the world does have an effect on demographics, at the end of the day. By now Git and GitHub have an essential, if controversial relationship.
averell 12y ago
>The people yelling at you are trying desperately to pretend like it was easy so they don’t feel like an idiot for how long it took them to figure things out. This in turn makes you feel like an idiot for taking so long to grasp the “easy” concept, so you happily pay it forward, and we come to one of the two great Emperor Has No Clothes moments in computing. This part doesn't make any sense. If anything, people would want to convince you it was hard to not look stupid for taking long. That being said the phenomenon clearly exists, but the reason is probably more along the lines of calling everything easy to try look smart in general.
- TeMPOraL 12y ago
  They want to convince you it's easy because they feel deep inside that if they were to explain things to you they'd realize they don't understand those things themselves. A person who understands something doesn't shout at you that it's easy (nor that it's hard). It just goes and explains it to you.
- redshirtrob 12y ago
  This drove me crazy too. I do not know anyone who conspicuously takes a long time to learn something, and then claims it's easy. In fact, it's quite the opposite, as you mentioned. Now, I have observed cases where someone inconspicuously took a long time to learn something and then claimed it was easy. This was more to elevate one's own intelligence in the eyes of another. As in, "Wow, this is really hard, but Joe said it was easy. He must be super brilliant." The other prevalent case of this behavior is when reading mathematic proofs. Often times you'll run across a statement in a proof along the lines of: "It's easy to see that X is true," for some statement X. But, X is always an existing result, and so this is really a way to focus on the details of the proof at hand and not get bogged down in proving every single non-trivial step. In fact, when I was a Mathlete, our coaches instructed us to make use of this approach, even if we weren't 100% sure that X was true. If we were pretty sure X was true, but we couldn't remember the proof, and we knew it would take prohibitively long to derive the proof, then we would make the statement.
kardashev 12y ago
I used to work at a place where our dev team was split in 2 and separated by 500 miles. We had centralized source control and there were days when our company network was slow. On those days I had to wait 30 minutes to check a file out and 30 minutes to check a file in. Try to meet deadlines with a workflow like that. Never again.
jnowlan 12y ago
Great article. Funny and knowledgeable. I know it's impossible but many of the comments here make it look like they didn't read the article. I guess if we followed 'best practices' we would be good.
sergiotapia 12y ago
I think the DVCS issues he mentioned are solved entirely. Just use the simple git-flow branching scheme. master = Code that is production ready. develop = Code for staging feature/XXX = Feature branches. Where is there room for confusion? It's dead simple and makes working with teams so easy and effortless. I would never join a team that uses something like Subversion or Perforce in these times. Git sucks for large blob files - no doubt. For those I recommend using Veracity.
deleted 12y ago
[deleted]
dasil003 12y ago
The author gives an excellent opening summary of the fundamental architecture of common VCSes over time, and then accurately identifies the most painful points of (eg) git, but then dramatically understates the benefits of a good DVCS. If you need binary files or otherwise very large repos, or centralized control and auditing, or non-developers to work with it, then git has major drawbacks. However there is so much code in the world—probably the majority—that works incredibly well with the full benefits of having it all in a single git repo. Having the whole history and the ability to mutilate it at will in a very fine-grained fashion is a power tool. I like it for the same reason I like vim: the learning curve is steep, but the idea is that this is a core tool I can use across programming languages for the duration of a 40, 50, 60 year career. I don't want to conflate something as horrible as svn with a theoretical good centralized VCS, but I have to say that using svn for 5 years I had much less idea how it worked then I did after 1 year of using git. Even though git was a steeper learning curve, the concepts in it are well-defined and the low-level pieces in it have a clarity of purpose which allows some implicit reasoning about the way things work without having to go in and actually read the source. This allows the fluent practitioner to devise flexible approaches to individual problems that a less modular system can not provide. I see commit messages and history as a fine craft. With git you can commit everything in small units that make sense only during construction as you are still exploring the problem space, then you can rebase it into cohesive changesets with deep documentation and a continuously unbroken build. A centralized VCS user could only achieve the same by withholding intermediate commits; that's okay, but it can become unwieldy for large changes. With git you can use initial commits like a master woodworker uses scrap wood, structuring them one way for building, and then discarding them in favor of finished pieces built to stand the test of time, providing massive forward benefit in terms of documentation/bisectability. Having worked on at least one project with a 7-year history, I can testify that investing in history curation pays huge dividends and can well make the difference between your successors thinking of you as a solid developer or a shotgun-programming hack.
kstenerud 12y ago
Problem 1: Developers unaware of the full capabilities of their DVCS system (thinking they can't do work because github is down). Solution: Education. Problem 2: Lots of versions of big blobs. Solution: git clone --depth 1 remote-url Problem 3: Big commit history. Solution: git clone --depth 1 remote-url Problem 4: Bad UX. Solution: Write a better UI, or find someone to do it. Linus is not a UX guy and never will be. Also, the example workflow differences are pretty similar to the differences between the github model and the Linux contribution model. This has nothing to do with DVCS vs VCS. So, in short, there's no actual fundamental problem with DVCS. Nothing to see here. Move along.
latj 12y ago
The author mentions that SVN is going to have branching. Users have had the ability to use branches in SVN via SVK for over a decade. Thats not the reason we switched to git. We switched to git because it made more sense and worked better, because every operation was faster in git, and because the development of the project was sure to progress. Github became popular years after git was already spreading.
- ternaryoperator 12y ago
  >Github became popular years after git was already spreading. That's technically true, but the implication is not. There was less than three years between the launches of git and GitHub. While git was becoming popular, it was just one of several (D)VCS solutions. GitHub is what really separated it from the rest of the pack.
bnastic 12y ago
Whenever I see an article like this I remember that Fossil and Perforce exist. And then I forget about them the next day.
Morst 12y ago
You do not have to clone the whole history of a repo with GIT. Solves most of your issues.
- Morst 12y ago
  git clone --depth <n> <url>
pointfree 12y ago
I wouldn't call darcs ( http://darcs.net/ http://darcs.net/ ) a failure. Darcs development is humming along and 2.11 is nearing release. Gone are the major performance issues with exponential merges and more recently, pushing large files. https://www.mail-archive.com/darcs-users@darcs.net/msg18423.html https://www.mail-archive.com/darcs-users@darcs.net/msg18423.... https://www.mail-archive.com/darcs-users@darcs.net/msg18425.html https://www.mail-archive.com/darcs-users@darcs.net/msg18425.... After having used git, darcs is a joy to use.
- drostie 12y ago
  Git's user interface is awful until you understand how the organic hairball underlying it is organized, at which point you can mostly "get it." Darcs' hand-holding approach to this is a great example of how to do it; Mercurial's also pretty good (for Hg you need about one tutorial and previous SVN experience, or two tutorials, to "get" it). What Darcs really lacks is a good "Tortoise" client for seamless Windows integration. It was tried (last release 8 years ago; I feel like I can safely talk in the past tense about it) but the userbase has not been large enough to sustain it.
- lobster_johnson 12y ago
  I and my teams used Darcs in two startups around 2005-2007, back just before and after 2.0. When it worked, it was pretty good. Darcs' UI was close to ideal. The interactive record prompt, for example (which git got after a while with the "-p" flag), was great. The way Darcs was able to infer dependencies between commits automatically and treat it more as a "sea of patches" rather than a linear history meant that it was very easy to work with branches. The problem was that as our codebase grew, it increasingly did not work. The infamous exponential conflict problem was just one of several bugs and performance issues that ended up costing us a lot of money in lost productivity. The problem was that when something went wrong, you probably couldn't fix it yourself. The only people who actually understood the internal database — not just the files on disk, but how it all fit together, including the "patch theory" — were the Darcs developers themselves, and not many people except David Roundy actually understood it from top to bottom. The fact that it was written in Haskell (which, at the time, was a lot more obscure than it is today) just made things worse. After a while we also found that the lack of a linear history had major downsides. Patch dependencies meant it was harder to cherry-pick; when you wanted to pick just one commit, it was often impossibly to understand why Darcs wanted to also pick a bunch of unrelated commits along with it, and from there on it got messy (and you increasingly risked bumping into the exponential merge bug). Git's history-rewriting tools cause more conflicts, but are ultimately simpler and easier to understand. Darcs' tragedy is probably that its performance problems burned so many people that they gave up and left it for Git or Mercurial, never to come back. We might have stuck with it longer, if it hadn't been for the aforementioned issues. On the bright side, even if Darcs hadn't had these issues, we probably would never have had a Darcshub.com, and Git would still have beaten the competition.
walkon 12y ago
Logic: claiming to be a current apologist of DVCS while simultaneously positing that DVCS should be abandoned.
dgemm 12y ago
The comments here trying to rebut every argument against DVCS are missing the point. The point is not that DVCS sucks and we should all go back to SVN - it's that since DVCS is fashionable, it is seen as a solution to every problem. Eventually this will wear off, and we will go back to using the simplest tool that gets the job done. For some jobs this will be DVCS, for others it won't.
MichaelGG 12y ago
Git snapped into focus and I've had little problems since I was told it's simple a DAG, and all the branch/tag/etc. stuff are just labels pointing to a part of the graph. After that, I've seriously never been in a situation where I was totally at a loss as to what was going on. Also, even in SF, Internet connectivity is often flaky enough that requiring a network roundtrip for anything to deal with my files is a non-starter. (Right now, downtown SF, and we only have a single Internet provider option. It goes to ~100% packet loss about 20 times a day. We get about 10-15Mbps out to the wider Internet (but 10x more to servers nearby - probably a shitty ISP using HE or something). So it's really quite a negative to need connectivity to do things.
- barrkel 12y ago
  Yup. I spent less time learning in total how git works than I have spent trying to figure out workable branch merging in svn. (For the latter, I ended up developing scripts that worked with patches as first class objects, so that e.g. every bug fix that needed to be applied on multiple branches would actually live in a patch file as my personal way of tracking a unit of work.) As to distribution, I spent 5 years as a remote developer working for a CA company from London. 200+ms round trips and occasional VPN weirdness meant painful sessions with svn. Having a local repo is excellent. Large binaries that constantly change are still a problem though.
- ufo 12y ago
  Mercurial and other DVCSs are also about simple DAGs but git has the disadvantage that you really need to learn the underlying data model and lots of terminology (trees, refs, blobs, revlog, etc)
gfunk911 12y ago
I fell in love with Git because I could do frequent local commits that matched my workflow, only "publishing" them when it was appropriate, in the format I wanted. Git did this for me, Subversion didn't. I know that concept does not have to be inherent to the D in DVCS. But for me that was the killer feature. It changed everything for me. The gain from being able to do that dwarfed all the costs of learning Git.
drawkbox 12y ago
With DVCS or any VCS you don't have to always have the full history. If it is a public project and open source you might want that. But if you are working on games or apps you might want a clean new remote after every so often so you aren't sending around a TB repo. When bitbucket limited to 2GB for repos, this limit can easily be breached on game projects, but it helped to really git submodule out libraries/code. This also encourages resetting history in a new repo every so often when that history is really not needed, like 2-3 versions back or after many months/years. Distributed VCS databases can get immense, but like anything in life, maintenance every once in a while helps. For some projects this is not possible like a linux kernel but for any old web site, app, game etc this is something that you can and should do. All operations are faster when your DVCS repo sizes are smaller.
- brianpgordon 12y ago
  If you're periodically clearing out your repository history, you're missing out on an extremely useful tool: blame. http://mislav.uniqpath.com/2014/02/hidden-documentation/ http://mislav.uniqpath.com/2014/02/hidden-documentation/
cssmoo 12y ago
Unpopular opinion here but we're using SVN here on a large project. No intention of changing it. Why? 1. Deterministic "whodunnit" as we have AD integrated with. That is needed when you have 220 people using a repo. 2. Partial check outs. Our platform is 6MLoC in total. 3. TortoiseSVN. Sorry there's nothing else out there as good as that. We use it for DMS tasks as well as you can merge word docs etc. 4. Binaries and locking. Works for design workflows and the odd file we can't merge easily (git/mercurial aren't magic bullets for that). 5. Centralised. All our shit is in one place so there's a "single source of truth". Also no patches flying around. 6. Easy to backup and replicate. Svndump into single file. Or svnsync and there's a true copy. 7. Perfect tooling/tracking integration due to the centralisation and hook support. 8. Easy to use for mere mortals (excel/word pokers). 9. Forces backup behaviour. A specific case but we had a couple of people using git and then pushing to our svn. One SSD fail and bang, the guy lost a week of work because he didn't push to master. Merge tracking is a non issue since 1.7 and if you need to work offline, just create patches and check them in when you're back online. Also our svn instance has been down for 3 minutes in the last 8 years... I really can't justify a move to a DVCS and lose all the above so I'm quite happy with my sanity.
- edwintorok 12y ago
  1. are you worried about people spoofing someone else's commiter/author entries? 2. `git clone --depth` or use submodules. I agree that they're not very friendly to use. 5. you can easily have a centralized place where everyone pushes 'master' with git 6. `git push --mirror` to some other place 7. you can have hooks on your git server too (for email, continous integration, etc.) 9. even with SVN I was using git-svn (and svk) before that purely for the offline commit feature, or having the ability to do more than one local commit at a time and push a tested set. In your case it wouldn't have made a difference whether your server was SVN or git, I would've still used svk or git-svn locally. Backups are important, have people run a daily backup on their workstations (like duplicity, but for a LAN even something like rsnapshot would work nicely). You might think SVN saves you until you find out that they forgot to 'svn add'/ a file (or whatever the equivalent was) and they mistakenly cleaned their source tree and now its gone for good.
  - 12y ago
novaleaf 12y ago
TLDR; Large binary assets are handled poorly by Git/Mercurial. I too have been bitten hard by this. Being a mercurial user, I tried large-file-extensions but on a team this leads to file corruption/non-synchronization too often to be practical. The most practical "solution" I've found is to actually ignore the issue. When your repository gets too bloated, start a new one.
- sytse 12y ago
  Consider using git-annex, it is quite good. We include it by default in GitLab Enterprise Edition.
joewood1972 12y ago
Not to diminish the argument, but other than diskspace, I really don't understand the downsides described here. I'm wondering, given the author was an early adopter of Git, this is purely hipster syndrome. Everybody is using it, so it's not cool any more.
samrift 12y ago
Here's my problem with this article: Return to sanity by adopting what? I work on several small-ish projects, and due to the leads coming and going, there are a smattering of source control solutions. On a weekly basis, I use SVN, TFS, and Git about equally. However, the workflow supported by Git is by far the best for me: I can commit locally as much as I want, rebase the commits or just merge them with work other people are doing, bisect if I broke something, and even branch locally to experiment or when I get interrupted by a question or another task. Neither TFS nor SVN support this at all. With both of them, I can't really check in until I'm completely done and sure I won't break the build or tests. I end up zipping my directory or fighting with patches/shelvesets that don't do what I want. Now, does the way I want to work require a DVCS? I don't know - perhaps it doesn't in a theoretical sense. However, DVCS is the only one that actually supports that now. So sure, we all push to the same repository and it could be a centralized system. But what would actually work? What can I switch to? I'm not abandoning Git for TFS or SVN, that's for sure. Nor Perforce which was also painful. Yes, you convinced me I don't need the "D" in DVCS. So make a CVS that supports local branching, commiting, sane merging and diffing and show it to me! But complaining that I'm not using one of the features of my DVCS has no bearing on if I should abandon it or not.
jrochkind1 12y ago
I like a lot of things about git over svn... the 'distributed' nature actually _isn't_ one of them, I think a canonical source location is about the only sane way to manage distributed software development. However, I think it's the distributed nature that leads to the much more powerful branch/merge functionality, which IS top on my list? (Git's UI is also not one of the things I like the best. It is a mess, indeed. Yes, because it was not originally intended as an end-user UI. So what, it is the end-user UI anyway, and it's a kind of ridiculously confusing and inconsistent one).
moron4hire 12y ago
Is Git really that hard to use? I know it took me awhile to learn how to find the right documentation for things, but that's significantly easier these days thanks to StackOverflow and the like. All told, I don't find Git significantly more difficult than the other tasks I have to do for my job. Usually, the troubles I have had with Git were because I tried to do something the wrong way. And if you don't like the documentation, well, there's more than one way to contribute to an open source project. And you could make an argument about Git specifically having bad UX in certain ways, but that isn't an argument against DVCS in general. There are problems and bugs with every VCS out there, but I've never encountered one with Git that left me completely useless for a day, or with a completely corrupted, unrecoverable repository. I've heard of such things happening in Git, but it hasn't happened to me in 5 years of using it. I've had that happen to me, personally, once every 8 to 12 months using SVN. The we thought SVN was a godsend back then was because it wasn't the 3 to 4 months that was SourceSafe or the monthly rate that was CVS. Okay, I'm being bit hyperbolic there, but not by much. And you can model centralized VCS in DVCS--evidenced by the fact that many peopled do do that with Github and it's ilk--meaning that systems that can only do centralized VCS are defective. Git can do everything SVN can do, but SVN can't do everything Git can do. If your central SVN repository goes down, you're pretty much SOL until it comes back, and you might even be SOL if and when it does come back. If GitHub goes down, I'm mildly inconvenienced when I have to add a new remote to my repository when I need to, say, share code with a colleague, or perform a deployment. The argument about contributions is... it's not about Git or DVCS at all. It's about GitHub and/or bad project maintainers. And he even admits that, but then acts like he's delivered a blow against the general concept of DVCS. The argument about blobs is an argument against Git, but not DVCS. I can't speak to Hg or Baz. I've heard they are easier to work with than Git. But I just can't imagine giving up the things Git gives me to go back to SVN. If someone on one of my projects suggested such a thing, it would seriously call into question for me that person's expertise.
- acveilleux 12y ago
  Well, I picked up CVS in about 30 minutes. Getting the nuance of DVCS right is much harder, at least when used in a distributed way with a team. I learned Mercurial first and Git still took me longer to grok.
erikb 12y ago
There are so many comments, probably nobody will read this. But I have to say it any way. The author seems to know a lot about many different things. But still it feels like he falls into the same trap as most people: Things never really just work. Life is always way more complicated than we would assume at first. SVN does not make most people happy, because it is more simple. If it is more simple there are a lot of things it can't do. Some people do something fast and simple for you and you think it works. But a week later a coworker needs to spend half the week to make it actually work. And even 10 years later you spend a significant amount of work to make it do things it doesn't do by itself. Learning a complex tool to do a complex task is really getting you closer. Because after you have spent the time learning it you can spend the same short time periods to achieve a much wider range of tasks, solve much wider sets of problems with each solution, etc.
sytse 12y ago
Great article and a good wakeup call on what to improve in Git. I don't agree that git-annex is centralized by nature. You can choose to download all the binaries and upload them to another server. Not everyone might do that if it is multiple TB's but it is much easier to work with multiple remotes than in a centralized system
Guthur 12y ago
I think the problem for this guy is Git. In my opinion Git user experience is plain horrid, nothing to do with DVCS just Git. Personally I find Mercurial a lot more pleasant to use. Not sure how repo size is really an issue in the age of multi terabyte personal storage, it's even possible to get SSD of that size without breaking the bank.
mark_l_watson 12y ago
Interesting article. svn's scruffiness contributed to git's success. A little off topic: I tend to work on projects by myself, especially since I have more or less turned off my consulting business. I have some git repos that I have been tempted to rm .git, git init, git add remote origin, and git push -u --force origin master. I have deep backups of everything so losing history to save a lot of space would be good. I didn't used to care about disk space but my two favorite laptops have moderate sized SSDs.
tomjen3 12y ago
Give me a centralized system that allows me to branch as easily as git, and has git stash. Is Git crap? Yep, unfortunately people went with github over bitbucket, despite bitbucket having a much better pricing model and as a result git is what people use for a DVCS. I would love for somebody to write a centralized version control system that would be a complete replacement for SVN, the way SVN replaced CVS but until somebody does a DVCs is what we have.
talideon 12y ago
He seems to have forgotten that most DVCSs allow you to perform lightweight clones, so you don't need to pull down the whole repo.

331 points by drostie 12y ago

grabcocque 12y ago

Github link to his proof-of-concept centralised VCS that doesn't suck..? That's what I thought.

xtrumanx 12y ago
Do you think its unacceptable to criticize the best product in a category because there's nothing better than it? His point was DVCSs like Git and Mercurial may have been an improvement in lots of aspects of version control system but they have taken some steps backwards as well. I thought he was kidding about the crazy juice...
terrywilcox 12y ago
Why would anybody writing a new VCS use Github to host it? Wouldn't it make more sense to use the new VCS itself. You know, eat your own dogfood?
- jusio 12y ago
  Not everyone is using GitHub for source hosting, there quite a few companies, which use internally some other VCS (like Perforce) and publish the sources on GitHub.
ngoldbaum 12y ago
Facebook and google are working on turning mercurial into such a VCS, although it will still be a DVCS allowing fully local commits (albeit without storing the full history on all clients). Take a look at the remotefilelog extension.

jimktrains2 12y ago

> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging. No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing. > Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. Well lucky him for only being able to code when he has a nice connection, not all of us do. Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?

grabcocque 12y ago
I fell in love with git because it's FAST. And it's fast because it's distributed.
- bryanlarsen 12y ago
  Have you ever used Perforce?
  - jimktrains2 12y ago
    You mean that proprietary code? No, I avoid non F/OSS at all costs.
    - politician 12y ago
      Wherein it is pointed out that Hacker News is proprietary software.
      - jcl 12y ago
        Really? https://github.com/wting/hackernews https://github.com/wting/hackernews
        squeaky-clean 12y ago
        Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".
        vonmoltke 12y ago
        https://github.com/wting/hackernews/blob/master/copyright https://github.com/wting/hackernews/blob/master/copyright
      - jimktrains2 12y ago

joosters 12y ago

I think the author is just misunderstanding most people's use of version control. We learn a tool well, so we continue to use it in situations where it might not be the best for the job in hand, or might be over-engineered for the purpose. Git falls into this use case a lot because once you understand how to use it, why not continue to use it, even if the project doesn't really need distributed version control. It's a waste of time to learn a new system. Personally I've never even bothered to learn git. I used to use Perforce at work, now I use it for my own projects. It does the job well, why switch?

iand675 12y ago

Anyone else remember the days when having your SVN server go down meant that you more or less had to wait until the server came back up before you could get back to doing things? (if you wanted a nice atomic commit). Let's not forget people that have to travel a lot for work– SVN + airplanes is a match made in hell. Anyone else ever had someone delete or close an open source project that you cared about? Finding a copy with the history that mattered to you could be tricky. Anyone else ever needed their own fork of something due to differing goals from the parent project, but needed to fold in upstream changes relatively often? That's by nature the sort of problem that a DVCS solves easily. Other objections to this article: * Nothing precludes you from using the patch model with DVCS (I mean, Linux kernel development uses Git just fine with this) * The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. I don't know what the status is for committing to them these days, but there's nothing fundamental that should prevent a DVCS from letting you work on shallow clones if space is such a big deal. I could go on, but the article seems to be griping about UX issues. Just because we haven't had tools in this space with wide adoption that are user friendly doesn't mean that we won't eventually.

masklinn 12y ago
> The author mentions that you have to retain the whole history of a project. For one thing, storage is cheap. Another point worth mentioning is that you can make shallow clones with Git. And for a third, it opens options which are not available without that. Annotating or bisecting with server round-trips every time is not really an option.
- CHY872 12y ago
  I disagree - I've done bisects on very large codebases, and they take a while (5-10 seconds for a checkout, perhaps). This is all immaterial compared to the time to recompile the code (possibly a minute or two to get everything recompiled (a Java project)).
  - jsight 12y ago

pron 12y ago

Note that the author of the article doesn't advocate forgoing local commits, but something like Facebook's work on a semi-distributed Mercurial, which allows local commits without cloning the entire history to each client. Here's the relevant section from the linked post[1]: But what if the central Mercurial server goes down? A big benefit of distributed source control is the ability to work without interacting with the server. The remotefilelog extension intelligently caches the file revisions needed for your local commits so you can checkout, rebase, and commit to any of your existing bookmarks without needing to access the server. Since we still download all of the commit metadata, operations that don't require file contents (such as log) are completely local as well. [1] https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

baldfat 12y ago

I use GIT for backup. the D allows this to happen and if I goof I can always go back to where I was. Always worth it for a single workflow.

jlarocco 12y ago

> Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. And this is merely going down over time as bandwidth gets ever more readily available. If you work as a field tech, or on a space station, or in a submarine or something, then okay, sure, this is a huge feature for you. Or if you're a Kiln customer, and their site is taking 4 minutes to load a page, assuming it's not just down... Sorry, couldn't resist... Seriously, though, I don't see where the author is going with his rant. It doesn't say much, and almost seems like a snide jab at Git and GitHub. None of his points are very good. Yeah, it doesn't take a DVCS to treat the whole repo as a unit. But right now they're the only ones who do. A hypothetical patch to SVN doesn't help me much. Also, I know from experience that SVN is horrible at binary files, and especially horrible at large binary files. I'm not saying Git and Mercurial are great, but they're no worse than SVN. The entire section about the amount of books and documentation is just silly. There was a LOT more subversion info around than "just the Red book". I owned two books, and I know we had a few different ones floating around the office, not to mention boatloads of tutorials and guides online. It's also funny how he makes fun of GitHub's git tutorial, but doesn't mention Kiln's Mercurial and Git tutorials. He also rips on GitHub's pull requests, but fails to mention that they work better than Kiln's. But it's great to see the founder of Kiln telling everybody not to use the technology his company is based on...

Tobani 12y ago
Interesting about kiln. My interpretation was: 1) Rant about a problem specific to you... 2) Provide no meaningful guidance or solution... (Except move back to SVN to solve a problem I don't have) 3) Make it to the top of Hacker News? 4) ??? 5) Profit?
- netghost 12y ago
  Actually he does point folks towards the work being done with Mercurial to embrace the centralized + offline commits model. Facebook's apparently been building some good stuff around that.

nightski 12y ago

Are these complaints all against DVCS? It seems a lot of them if not all are just shortcomings of currently available offerings (git/mercurial) whereas the author is directing them at DVCS directly.

brockers 12y ago

The best part of the whole article was the line: >> "If you say something’s hard, and everyone starts screaming at you—sometimes literally—that it’s easy, then it’s really hard.

makmanalp 12y ago

> No, the only thing that a DVCS gets you, by definition, is that everyone gets a copy of the full offline history of the entire repository to do with as you please. > Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times. > That’s fine for a centralized system. You only have one copy at any give point, so the amount of disk space you need is basically the size of the current (or target) version of the repository—not the whole thing. > This means that changing a file in a deep directory will require generating new trees for every directory up the chain—and, of course, that figuring out what changed in a given directory requires loading up all the trees going down the chain. Wondered why git blame runs slow as hell on big repos? Now you know. (is this even true? Git blame is slow because it digs through history) > Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. People will write books about anything because people will read books about anything. > Indeed, to listen to this, you would believe that open-source development was impossible, or at least absolutely horrible, before GitHub sprang into melodious existence. The pull request critique is so silly I'm not even going to try. ---- I really don't see how any of his critiques have to do with DVCS vs VCS. Literally none of them. This really is a Git rant. If you don't like Git, I guess that's fine. The problem with git is it's more building block than slick foolproof user tool, but some of us like it that way. Git is the first prominent example of someone thinking hard about the low-level theoretical implications of version control (the idea of the state of the entire repo as a changeset, the underlying data structures, etc), and then building a tool around it that works well. When I look at SVN, for example, it's not obvious what the hell we were even thinking - there was no theoretical framework, it was just the simplest thing that worked. And it didn't work well. Branches were more of a pain than a feature. So yeah, there's obviously room for improvement, but I don't even understand the complaint against DVCS in general here. edit: formatting edit2: or rather, it's about the current state of DVCSes, but I don't see how most of these would be made better by switching back to a centralized VCS and I'm not convinced that improving these are mutually exclusive with having a distributed version control system. I think there's come conflation of concepts going on here.

eos_styx 12y ago

syntern 12y ago

I think that a combination works best, but it looks like not many do a central SVN + local git setup. Any reason for that? Do you have bad time with that or what? The central SVN is much better for tracking versions for release purposes, while the local git has all the benefits of working on one thing than switching to another. Any thoughts?

syntern 12y ago
Basically this: https://www.kernel.org/pub/software/scm/git/docs/git-svn.html https://www.kernel.org/pub/software/scm/git/docs/git-svn.htm... http://flavio.castelli.name/2007/09/04/howto_use_git_with_svn/ http://flavio.castelli.name/2007/09/04/howto_use_git_with_sv... http://andy.delcambre.com/2008/03/04/git-svn-workflow.html http://andy.delcambre.com/2008/03/04/git-svn-workflow.html

etep 12y ago

This: Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website.

jimktrains2 12y ago
You do know that there are many multiple SVN books out there in addition to the red book?
- ams6110 12y ago
  But you don't really need them. The red book tells you pretty much all there is to know (I say that based on memory from years ago, the last time I used SVN. I liked SVN. It was easy to use, easy to understand, and did everything we needed for our project (a half a dozen developers all working in one office). It was such a breath of fresh air coming from our previous VCS (Visual SourceSafe).
  - jimktrains2 12y ago
    And you don't really _need_ a git book either. There is a lot of nice information on the git site and the man pages (even considering the man pages notoriety in not being consistent in terminology).
    - pwang 12y ago
      Which is why the nvie.com "git flow" (that everyone points to as the ideal branching model for git) is not actually on the git site? And as for git man pages... I have been hacking on Linux and complex codebases for 20+ years at this point but have never been so befuddled as I have been by the git man pages.
ambrice 12y ago
So, going by the number of books and tutorials metric, java is a much more complicated programming language than erlang? Have you seen how many books and tutorials java needs?

greggman 12y ago

svn isn't really a solution for binary files. It also requires workarounds. Sure it doesn't have the issue of every version of every blob but it still needs 2 versions of every blob. If you're on a game with terabytes of source data which is common for a AAA game 2x terabytes is not a win. It also doesn't help you manage collisions by locking every UNMERGABLE binary file so you know before you edit if someone else is or has already edited the file. I know you can set local options to make it lock the files but that feels more like a workaround.

stsp 12y ago
Binary files are by definition unmergeble with a diff3 algorithm implementation that uses text tokens separated by \n. Specific software to merge a binary file format can be used with virtually any version control system if available. You can set an svn:needs-lock property on binaries. It is not a local option, it applies to everyone using the repository. For extra convience, use svn:auto-props (acts recursively) to set it by default on new files which match a particular filename pattern (e.g. match on file name extension). http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config http://subversion.apache.org/docs/release-notes/1.8.html#rep... EDIT: That said, I agree that some types of binary files really have no place in SVN repositories. One example are release artifacts, as stored e.g. in Maven repositories.

huu 12y ago

I don't think the existence of more books for git as opposed to svn proves that it is more difficult. I think it's more a reflection of how popular/accessible git is, and publishing more books is a way for the market to address a bigger audience.

karmajunkie 12y ago

I had no idea there were so many repressed SVN-loving developers out there.

matthewmacleod 12y ago

Of all the problems we have as an industry, I'm convinced that version control is near the bottom of the list. Sure, 'DVCS' in the form of git or mercurial doesn't deal well with binary files, and has large repo sizes. If these are problems, you might be using the wrong tool. But that's fine; pretty much everybody should be using something like git or mercurial. They're flexible, relatively easy-to-use, and cover almost all use cases. If you need to store large frequently-changing binary blobs, then you are probably in a minority; there's nothing really wrong with git-annex for managing that content. But this whole thing we're seeing at the moment with people objecting to DVCS utterly mystifies me, as someone who went from CVS to SVN to git and has utterly no interest in going back.

balabaster 12y ago

Hahahaha love this. But I think all version control systems suck - not inherently, but because their usability is atrocious. I enjoy Git... well, perhaps enjoy is a strong word, perhaps what I really mean is I have Stockholm Syndrome. I've tried to go back to TFS, SVN and other centralized systems, but I'm too emotionally bonded to having my source control system with me, everywhere I go... Starbucks, Tim Hortons, the Train, sitting on the beach. But I don't delude myself into thinking this is anything more than emotional. I like having it there, it gives me comfort - and there is some convenience. I don't want to have to worry about "How do I undo all those changes from my last 10 commits and go back to where I started down this path?" Git gives me that nice fuzzy feeling of being able to play meaninglessly with my code until something takes form and if it comes to nothing, I can do git reset --hard 1f3c2047 and I'm right back to where I was before I went down this path of insanity...and if it takes a nice form, I can do git rebase -i and squash all my messy commits into a single commit with a single commit message. I didn't need to branch, I didn't need to clone, I didn't need to do anything crazy, I just fire up Bash and I'm done, no muss, no fuss, no having to be connected to the source control server, no dependence on anyone else... and if I did want to put that code aside, I can stash it or spin it onto another branch before coming back to my original branch and resetting back to a sane commit. It's nice having ultimate control. But having that amount of control has its drawbacks...you can't expect the ability to drive stick, but not have to learn how to use a clutch and gearshift.

hpaavola 12y ago

What are the (open source) centralized version control systems that do merging and branching like git?

zo1 12y ago

>"The actual reason is because GitHub let coders cleanly publish code portfolios, and GitHub happened to use Git as the underlying technology to enable that," Is this guy genuinely suggesting that people fell in "love" with distributed version control solely because of GitHub? I don't feel old enough to be telling this author to get off my lawn. I mean, GitHub is great and all, but it does not represent the sum whole of all the commits in this world. Granted, does anyone know the timelines of when DVCS took off (as opposed to launched)? Mercurial and Git were both released a good 3 years before GitHub was launched. Okay, I looked up more about DVCS. Wikipedia article's history section on it: History Closed source DVCS systems such as Sun WorkShop TeamWare were widely used in enterprise settings in the 1990s and inspired BitKeeper (1998), one of the first open systems. BitKeeper went on to serve in the early development of the Linux kernel. First generation open-source DVCS systems include Arch and Monotone. The second generation was initiated by the arrival of Darcs, followed by a host of others. When the publishers of BitKeeper decided in 2005 to restrict the program's licensing,[5] free alternatives Bazaar, Git, and Mercurial followed not long after.

Zelphyr 12y ago
I had the misfortune to have used Arch around 2005-2007. That was an excruciating experience. Updates that would take over an hour.
vezzy-fnord 12y ago
I think both of you are respectively overestimating and underestimating the significance of GitHub. Are there a lot of projects that use Git without a hosting intermediary because of genuine advantages? Yes, absolutely. Plenty of core infrastructure and applications, many of which significantly predate Git or GitHub. Is there a growing subculture of people who essentially equate Git with GitHub and end up completely subverting the "D" in DVCS, incurring unnecessary downtime and who pretend Git/GitHub are the be-all-end-all? Also yes, with circles such as those of HN being overrepresented with "GitHub is your resume" rhetoric and various startups or hip SaaS having GitHub be their single point of failure. Being the #1 software hosting site in the world does have an effect on demographics, at the end of the day. By now Git and GitHub have an essential, if controversial relationship.

averell 12y ago

>The people yelling at you are trying desperately to pretend like it was easy so they don’t feel like an idiot for how long it took them to figure things out. This in turn makes you feel like an idiot for taking so long to grasp the “easy” concept, so you happily pay it forward, and we come to one of the two great Emperor Has No Clothes moments in computing. This part doesn't make any sense. If anything, people would want to convince you it was hard to not look stupid for taking long. That being said the phenomenon clearly exists, but the reason is probably more along the lines of calling everything easy to try look smart in general.

TeMPOraL 12y ago
They want to convince you it's easy because they feel deep inside that if they were to explain things to you they'd realize they don't understand those things themselves. A person who understands something doesn't shout at you that it's easy (nor that it's hard). It just goes and explains it to you.
redshirtrob 12y ago
This drove me crazy too. I do not know anyone who conspicuously takes a long time to learn something, and then claims it's easy. In fact, it's quite the opposite, as you mentioned. Now, I have observed cases where someone inconspicuously took a long time to learn something and then claimed it was easy. This was more to elevate one's own intelligence in the eyes of another. As in, "Wow, this is really hard, but Joe said it was easy. He must be super brilliant." The other prevalent case of this behavior is when reading mathematic proofs. Often times you'll run across a statement in a proof along the lines of: "It's easy to see that X is true," for some statement X. But, X is always an existing result, and so this is really a way to focus on the details of the proof at hand and not get bogged down in proving every single non-trivial step. In fact, when I was a Mathlete, our coaches instructed us to make use of this approach, even if we weren't 100% sure that X was true. If we were pretty sure X was true, but we couldn't remember the proof, and we knew it would take prohibitively long to derive the proof, then we would make the statement.

kardashev 12y ago

I used to work at a place where our dev team was split in 2 and separated by 500 miles. We had centralized source control and there were days when our company network was slow. On those days I had to wait 30 minutes to check a file out and 30 minutes to check a file in. Try to meet deadlines with a workflow like that. Never again.

jnowlan 12y ago

Great article. Funny and knowledgeable. I know it's impossible but many of the comments here make it look like they didn't read the article. I guess if we followed 'best practices' we would be good.

sergiotapia 12y ago

I think the DVCS issues he mentioned are solved entirely. Just use the simple git-flow branching scheme. master = Code that is production ready. develop = Code for staging feature/XXX = Feature branches. Where is there room for confusion? It's dead simple and makes working with teams so easy and effortless. I would never join a team that uses something like Subversion or Perforce in these times. Git sucks for large blob files - no doubt. For those I recommend using Veracity.

deleted 12y ago

[deleted]

dasil003 12y ago

The author gives an excellent opening summary of the fundamental architecture of common VCSes over time, and then accurately identifies the most painful points of (eg) git, but then dramatically understates the benefits of a good DVCS. If you need binary files or otherwise very large repos, or centralized control and auditing, or non-developers to work with it, then git has major drawbacks. However there is so much code in the world—probably the majority—that works incredibly well with the full benefits of having it all in a single git repo. Having the whole history and the ability to mutilate it at will in a very fine-grained fashion is a power tool. I like it for the same reason I like vim: the learning curve is steep, but the idea is that this is a core tool I can use across programming languages for the duration of a 40, 50, 60 year career. I don't want to conflate something as horrible as svn with a theoretical good centralized VCS, but I have to say that using svn for 5 years I had much less idea how it worked then I did after 1 year of using git. Even though git was a steeper learning curve, the concepts in it are well-defined and the low-level pieces in it have a clarity of purpose which allows some implicit reasoning about the way things work without having to go in and actually read the source. This allows the fluent practitioner to devise flexible approaches to individual problems that a less modular system can not provide. I see commit messages and history as a fine craft. With git you can commit everything in small units that make sense only during construction as you are still exploring the problem space, then you can rebase it into cohesive changesets with deep documentation and a continuously unbroken build. A centralized VCS user could only achieve the same by withholding intermediate commits; that's okay, but it can become unwieldy for large changes. With git you can use initial commits like a master woodworker uses scrap wood, structuring them one way for building, and then discarding them in favor of finished pieces built to stand the test of time, providing massive forward benefit in terms of documentation/bisectability. Having worked on at least one project with a 7-year history, I can testify that investing in history curation pays huge dividends and can well make the difference between your successors thinking of you as a solid developer or a shotgun-programming hack.

kstenerud 12y ago

Problem 1: Developers unaware of the full capabilities of their DVCS system (thinking they can't do work because github is down). Solution: Education. Problem 2: Lots of versions of big blobs. Solution: git clone --depth 1 remote-url Problem 3: Big commit history. Solution: git clone --depth 1 remote-url Problem 4: Bad UX. Solution: Write a better UI, or find someone to do it. Linus is not a UX guy and never will be. Also, the example workflow differences are pretty similar to the differences between the github model and the Linux contribution model. This has nothing to do with DVCS vs VCS. So, in short, there's no actual fundamental problem with DVCS. Nothing to see here. Move along.

latj 12y ago

The author mentions that SVN is going to have branching. Users have had the ability to use branches in SVN via SVK for over a decade. Thats not the reason we switched to git. We switched to git because it made more sense and worked better, because every operation was faster in git, and because the development of the project was sure to progress. Github became popular years after git was already spreading.

ternaryoperator 12y ago
>Github became popular years after git was already spreading. That's technically true, but the implication is not. There was less than three years between the launches of git and GitHub. While git was becoming popular, it was just one of several (D)VCS solutions. GitHub is what really separated it from the rest of the pack.

bnastic 12y ago

Whenever I see an article like this I remember that Fossil and Perforce exist. And then I forget about them the next day.

Morst 12y ago

You do not have to clone the whole history of a repo with GIT. Solves most of your issues.

Morst 12y ago
git clone --depth <n> <url>

pointfree 12y ago

I wouldn't call darcs ( http://darcs.net/ http://darcs.net/ ) a failure. Darcs development is humming along and 2.11 is nearing release. Gone are the major performance issues with exponential merges and more recently, pushing large files. https://www.mail-archive.com/darcs-users@darcs.net/msg18423.html https://www.mail-archive.com/darcs-users@darcs.net/msg18423.... https://www.mail-archive.com/darcs-users@darcs.net/msg18425.html https://www.mail-archive.com/darcs-users@darcs.net/msg18425.... After having used git, darcs is a joy to use.

drostie 12y ago
Git's user interface is awful until you understand how the organic hairball underlying it is organized, at which point you can mostly "get it." Darcs' hand-holding approach to this is a great example of how to do it; Mercurial's also pretty good (for Hg you need about one tutorial and previous SVN experience, or two tutorials, to "get" it). What Darcs really lacks is a good "Tortoise" client for seamless Windows integration. It was tried (last release 8 years ago; I feel like I can safely talk in the past tense about it) but the userbase has not been large enough to sustain it.
lobster_johnson 12y ago
I and my teams used Darcs in two startups around 2005-2007, back just before and after 2.0. When it worked, it was pretty good. Darcs' UI was close to ideal. The interactive record prompt, for example (which git got after a while with the "-p" flag), was great. The way Darcs was able to infer dependencies between commits automatically and treat it more as a "sea of patches" rather than a linear history meant that it was very easy to work with branches. The problem was that as our codebase grew, it increasingly did not work. The infamous exponential conflict problem was just one of several bugs and performance issues that ended up costing us a lot of money in lost productivity. The problem was that when something went wrong, you probably couldn't fix it yourself. The only people who actually understood the internal database — not just the files on disk, but how it all fit together, including the "patch theory" — were the Darcs developers themselves, and not many people except David Roundy actually understood it from top to bottom. The fact that it was written in Haskell (which, at the time, was a lot more obscure than it is today) just made things worse. After a while we also found that the lack of a linear history had major downsides. Patch dependencies meant it was harder to cherry-pick; when you wanted to pick just one commit, it was often impossibly to understand why Darcs wanted to also pick a bunch of unrelated commits along with it, and from there on it got messy (and you increasingly risked bumping into the exponential merge bug). Git's history-rewriting tools cause more conflicts, but are ultimately simpler and easier to understand. Darcs' tragedy is probably that its performance problems burned so many people that they gave up and left it for Git or Mercurial, never to come back. We might have stuck with it longer, if it hadn't been for the aforementioned issues. On the bright side, even if Darcs hadn't had these issues, we probably would never have had a Darcshub.com, and Git would still have beaten the competition.

walkon 12y ago

Logic: claiming to be a current apologist of DVCS while simultaneously positing that DVCS should be abandoned.

dgemm 12y ago

The comments here trying to rebut every argument against DVCS are missing the point. The point is not that DVCS sucks and we should all go back to SVN - it's that since DVCS is fashionable, it is seen as a solution to every problem. Eventually this will wear off, and we will go back to using the simplest tool that gets the job done. For some jobs this will be DVCS, for others it won't.

MichaelGG 12y ago

Git snapped into focus and I've had little problems since I was told it's simple a DAG, and all the branch/tag/etc. stuff are just labels pointing to a part of the graph. After that, I've seriously never been in a situation where I was totally at a loss as to what was going on. Also, even in SF, Internet connectivity is often flaky enough that requiring a network roundtrip for anything to deal with my files is a non-starter. (Right now, downtown SF, and we only have a single Internet provider option. It goes to ~100% packet loss about 20 times a day. We get about 10-15Mbps out to the wider Internet (but 10x more to servers nearby - probably a shitty ISP using HE or something). So it's really quite a negative to need connectivity to do things.

barrkel 12y ago
Yup. I spent less time learning in total how git works than I have spent trying to figure out workable branch merging in svn. (For the latter, I ended up developing scripts that worked with patches as first class objects, so that e.g. every bug fix that needed to be applied on multiple branches would actually live in a patch file as my personal way of tracking a unit of work.) As to distribution, I spent 5 years as a remote developer working for a CA company from London. 200+ms round trips and occasional VPN weirdness meant painful sessions with svn. Having a local repo is excellent. Large binaries that constantly change are still a problem though.
ufo 12y ago
Mercurial and other DVCSs are also about simple DAGs but git has the disadvantage that you really need to learn the underlying data model and lots of terminology (trees, refs, blobs, revlog, etc)

gfunk911 12y ago

I fell in love with Git because I could do frequent local commits that matched my workflow, only "publishing" them when it was appropriate, in the format I wanted. Git did this for me, Subversion didn't. I know that concept does not have to be inherent to the D in DVCS. But for me that was the killer feature. It changed everything for me. The gain from being able to do that dwarfed all the costs of learning Git.

drawkbox 12y ago

With DVCS or any VCS you don't have to always have the full history. If it is a public project and open source you might want that. But if you are working on games or apps you might want a clean new remote after every so often so you aren't sending around a TB repo. When bitbucket limited to 2GB for repos, this limit can easily be breached on game projects, but it helped to really git submodule out libraries/code. This also encourages resetting history in a new repo every so often when that history is really not needed, like 2-3 versions back or after many months/years. Distributed VCS databases can get immense, but like anything in life, maintenance every once in a while helps. For some projects this is not possible like a linux kernel but for any old web site, app, game etc this is something that you can and should do. All operations are faster when your DVCS repo sizes are smaller.

brianpgordon 12y ago
If you're periodically clearing out your repository history, you're missing out on an extremely useful tool: blame. http://mislav.uniqpath.com/2014/02/hidden-documentation/ http://mislav.uniqpath.com/2014/02/hidden-documentation/

cssmoo 12y ago

Unpopular opinion here but we're using SVN here on a large project. No intention of changing it. Why? 1. Deterministic "whodunnit" as we have AD integrated with. That is needed when you have 220 people using a repo. 2. Partial check outs. Our platform is 6MLoC in total. 3. TortoiseSVN. Sorry there's nothing else out there as good as that. We use it for DMS tasks as well as you can merge word docs etc. 4. Binaries and locking. Works for design workflows and the odd file we can't merge easily (git/mercurial aren't magic bullets for that). 5. Centralised. All our shit is in one place so there's a "single source of truth". Also no patches flying around. 6. Easy to backup and replicate. Svndump into single file. Or svnsync and there's a true copy. 7. Perfect tooling/tracking integration due to the centralisation and hook support. 8. Easy to use for mere mortals (excel/word pokers). 9. Forces backup behaviour. A specific case but we had a couple of people using git and then pushing to our svn. One SSD fail and bang, the guy lost a week of work because he didn't push to master. Merge tracking is a non issue since 1.7 and if you need to work offline, just create patches and check them in when you're back online. Also our svn instance has been down for 3 minutes in the last 8 years... I really can't justify a move to a DVCS and lose all the above so I'm quite happy with my sanity.

edwintorok 12y ago
1. are you worried about people spoofing someone else's commiter/author entries? 2. `git clone --depth` or use submodules. I agree that they're not very friendly to use. 5. you can easily have a centralized place where everyone pushes 'master' with git 6. `git push --mirror` to some other place 7. you can have hooks on your git server too (for email, continous integration, etc.) 9. even with SVN I was using git-svn (and svk) before that purely for the offline commit feature, or having the ability to do more than one local commit at a time and push a tested set. In your case it wouldn't have made a difference whether your server was SVN or git, I would've still used svk or git-svn locally. Backups are important, have people run a daily backup on their workstations (like duplicity, but for a LAN even something like rsnapshot would work nicely). You might think SVN saves you until you find out that they forgot to 'svn add'/ a file (or whatever the equivalent was) and they mistakenly cleaned their source tree and now its gone for good.
- 12y ago

novaleaf 12y ago

TLDR; Large binary assets are handled poorly by Git/Mercurial. I too have been bitten hard by this. Being a mercurial user, I tried large-file-extensions but on a team this leads to file corruption/non-synchronization too often to be practical. The most practical "solution" I've found is to actually ignore the issue. When your repository gets too bloated, start a new one.

sytse 12y ago
Consider using git-annex, it is quite good. We include it by default in GitLab Enterprise Edition.

joewood1972 12y ago

Not to diminish the argument, but other than diskspace, I really don't understand the downsides described here. I'm wondering, given the author was an early adopter of Git, this is purely hipster syndrome. Everybody is using it, so it's not cool any more.

samrift 12y ago

Here's my problem with this article: Return to sanity by adopting what? I work on several small-ish projects, and due to the leads coming and going, there are a smattering of source control solutions. On a weekly basis, I use SVN, TFS, and Git about equally. However, the workflow supported by Git is by far the best for me: I can commit locally as much as I want, rebase the commits or just merge them with work other people are doing, bisect if I broke something, and even branch locally to experiment or when I get interrupted by a question or another task. Neither TFS nor SVN support this at all. With both of them, I can't really check in until I'm completely done and sure I won't break the build or tests. I end up zipping my directory or fighting with patches/shelvesets that don't do what I want. Now, does the way I want to work require a DVCS? I don't know - perhaps it doesn't in a theoretical sense. However, DVCS is the only one that actually supports that now. So sure, we all push to the same repository and it could be a centralized system. But what would actually work? What can I switch to? I'm not abandoning Git for TFS or SVN, that's for sure. Nor Perforce which was also painful. Yes, you convinced me I don't need the "D" in DVCS. So make a CVS that supports local branching, commiting, sane merging and diffing and show it to me! But complaining that I'm not using one of the features of my DVCS has no bearing on if I should abandon it or not.

jrochkind1 12y ago

I like a lot of things about git over svn... the 'distributed' nature actually _isn't_ one of them, I think a canonical source location is about the only sane way to manage distributed software development. However, I think it's the distributed nature that leads to the much more powerful branch/merge functionality, which IS top on my list? (Git's UI is also not one of the things I like the best. It is a mess, indeed. Yes, because it was not originally intended as an end-user UI. So what, it is the end-user UI anyway, and it's a kind of ridiculously confusing and inconsistent one).

moron4hire 12y ago

Is Git really that hard to use? I know it took me awhile to learn how to find the right documentation for things, but that's significantly easier these days thanks to StackOverflow and the like. All told, I don't find Git significantly more difficult than the other tasks I have to do for my job. Usually, the troubles I have had with Git were because I tried to do something the wrong way. And if you don't like the documentation, well, there's more than one way to contribute to an open source project. And you could make an argument about Git specifically having bad UX in certain ways, but that isn't an argument against DVCS in general. There are problems and bugs with every VCS out there, but I've never encountered one with Git that left me completely useless for a day, or with a completely corrupted, unrecoverable repository. I've heard of such things happening in Git, but it hasn't happened to me in 5 years of using it. I've had that happen to me, personally, once every 8 to 12 months using SVN. The we thought SVN was a godsend back then was because it wasn't the 3 to 4 months that was SourceSafe or the monthly rate that was CVS. Okay, I'm being bit hyperbolic there, but not by much. And you can model centralized VCS in DVCS--evidenced by the fact that many peopled do do that with Github and it's ilk--meaning that systems that can only do centralized VCS are defective. Git can do everything SVN can do, but SVN can't do everything Git can do. If your central SVN repository goes down, you're pretty much SOL until it comes back, and you might even be SOL if and when it does come back. If GitHub goes down, I'm mildly inconvenienced when I have to add a new remote to my repository when I need to, say, share code with a colleague, or perform a deployment. The argument about contributions is... it's not about Git or DVCS at all. It's about GitHub and/or bad project maintainers. And he even admits that, but then acts like he's delivered a blow against the general concept of DVCS. The argument about blobs is an argument against Git, but not DVCS. I can't speak to Hg or Baz. I've heard they are easier to work with than Git. But I just can't imagine giving up the things Git gives me to go back to SVN. If someone on one of my projects suggested such a thing, it would seriously call into question for me that person's expertise.

acveilleux 12y ago
Well, I picked up CVS in about 30 minutes. Getting the nuance of DVCS right is much harder, at least when used in a distributed way with a team. I learned Mercurial first and Git still took me longer to grok.

erikb 12y ago

There are so many comments, probably nobody will read this. But I have to say it any way. The author seems to know a lot about many different things. But still it feels like he falls into the same trap as most people: Things never really just work. Life is always way more complicated than we would assume at first. SVN does not make most people happy, because it is more simple. If it is more simple there are a lot of things it can't do. Some people do something fast and simple for you and you think it works. But a week later a coworker needs to spend half the week to make it actually work. And even 10 years later you spend a significant amount of work to make it do things it doesn't do by itself. Learning a complex tool to do a complex task is really getting you closer. Because after you have spent the time learning it you can spend the same short time periods to achieve a much wider range of tasks, solve much wider sets of problems with each solution, etc.

sytse 12y ago

Great article and a good wakeup call on what to improve in Git. I don't agree that git-annex is centralized by nature. You can choose to download all the binaries and upload them to another server. Not everyone might do that if it is multiple TB's but it is much easier to work with multiple remotes than in a centralized system

Guthur 12y ago

I think the problem for this guy is Git. In my opinion Git user experience is plain horrid, nothing to do with DVCS just Git. Personally I find Mercurial a lot more pleasant to use. Not sure how repo size is really an issue in the age of multi terabyte personal storage, it's even possible to get SSD of that size without breaking the bank.

mark_l_watson 12y ago

Interesting article. svn's scruffiness contributed to git's success. A little off topic: I tend to work on projects by myself, especially since I have more or less turned off my consulting business. I have some git repos that I have been tempted to rm .git, git init, git add remote origin, and git push -u --force origin master. I have deep backups of everything so losing history to save a lot of space would be good. I didn't used to care about disk space but my two favorite laptops have moderate sized SSDs.

tomjen3 12y ago

Give me a centralized system that allows me to branch as easily as git, and has git stash. Is Git crap? Yep, unfortunately people went with github over bitbucket, despite bitbucket having a much better pricing model and as a result git is what people use for a DVCS. I would love for somebody to write a centralized version control system that would be a complete replacement for SVN, the way SVN replaced CVS but until somebody does a DVCs is what we have.

talideon 12y ago

He seems to have forgotten that most DVCSs allow you to perform lightweight clones, so you don't need to pull down the whole repo.