1. 6
  1.  

  2. 16

    So, to summarize, “Distributed Version Control isn’t a good replacement for a release process”?

    1. 5

      Yes, “Nearly all users of version control are non-developers.” is the author’s thesis for why DVCS is bad. I personally also find it frustrating when someone writes a book about something they could communicate quickly and clearly.

      Their argument for why it’s bad for development is that their drive must be clean when crossing the US border as though that’s a problem that most people have.

      Their argument for why it’s bad for long lived development is “your checkouts will necessarily become too big and slow someday, if the project stays on this system long enough” , which the author really has no evidence for.

    2. 15

      The author wants to use the tool for tasks it is not designed for, or does not know how to use the tool correctly.

      Passing on “Distributed version control sucks for distributing software” which is just non-sense.

      1. Distributed version control sucks for distributed development

        The problem shows up when I’m sitting in my hotel room and need to re-create the local repository over the poor connection. Now I’m not just downloading the one revision I want to work on; I’m downloading every revision ever.

        Nothing forces you to do that in git. Just download the one revision you want to work on. This point reinforces also the idea that the author is certainly not working in the industry (academic setting) and seems to have no idea of necessary more advanced features used in developping complex systems collaboratively (with several products / features, in stable branches in which new features have to be backported).

      2. Distributed version control sucks for long-lived projects

        The history continues to grow; a single version doesn’t. This may be a smooth progression rather than a sudden state change: over time it becomes more the case that the history grows faster than the current version. And so a system that forces every copy to contain all of history will eventually, inevitably, have bigger copies than a system that only stores current versions.

        And then the author rants about DVCS sucking for archiving. And sees absolutely no contradiction in those two positions. If you forget your history because you only keep current versions, you are nor archiving anything. It is impossible to replicate a past version of a system, for historical purpose, exploration or just to help a user stuck with an old system.

      3. Distributed version control sucks for archiving

        Use a database.

      The author is just closed off in his own environment and has a poor grasp of the tools he is using on top of it. This rant is useless, and his peers were right to shut him off.

      1. 2

        Some times it’s easier to rant than to learn new things :p

        1. 1

          I didn’t like it either, but you’re strawmanning one criticism. I think OP’s claim is that a centralized repo is easier to archive because everything stays on a primary copy, with people subsetting into secondary copies. So it’s clear what to back up. There’s no contradiction there.

        2. 6

          Nearly all users of version control are non-developers.

          Citation needed.

          1. 4

            Another flaw in addition to what other commenters have pointed out.

            Although these issues could be mitigated in theory, that is not done in practice.

            But then you’re just criticizing git and how it’s used in practice, right? Why over-generalize to all of distributed version control?


            The GitHub thing also makes no sense. Git makes no assumption about the master repo, but nobody claims you don’t need one. GitHub filling the gap is precisely what the system was designed to enable: separation of concerns.

            1. 4

              This is a terrible article. Clearly the person who wrote it hasn’t thought very hard about what they’re writing about, because if they had, they’d realize that, as a for instance:

              “Distributed version control sucks because most users are non developers”

              Umm… So don’t make them use version control and provide them with tools that actually meet their needs?

              “Distributed version control sucks because it’s terrible at archiving.”

              If you’re using your VCS to store archives, you’re doing it wrong.

              DVCS aren’t perfect, far from it in fact, but reasons why one might say DVCS systems suck have very little to do with those put forth in this article.

              1. 4

                I only skimmed after the first few paragraphs, but I think each of his complaints applies equally to non-distributed version control.

                I’m also skeptical of his assumptions. Building from source is a developer activity. A clueless (for lack of a better word) end user, like “Joe”, will be in over their head regardless of the VCS used. And generally speaking, for any non-trivial software, cloning from the VCS is likely to be the easiest part of the process.

                1. 1

                  I didn’t read this novel, but I do think systems like SVN are under-appreciated.

                  At one point I set up a dropbox like system for completely non-technical employees to use. They just had to edit their documents in MS-{word,powerpoint,excel}, hit save, and then hit sync or whatever in TortoiseSVN and I basically never got any “I deleted everything, what is a staging area? omg I am freaking out right now” sort of support requests. The system never degraded when they accidentally committed massive files to the repo and then went “oops” and deleted them.

                  Good experiences had by all. Git would not have worked.

                  1. 3

                    I’d argue that what you want here is not a VCS and is in fact a document store. There are several good ones out there. I say manage your documents with tools for managing documents and manage your source with tools designed for that.

                    1. 2

                      Out of genuine curiosity, do you have recommendations for a good document store that does versioning?

                      I’ve committed stuff in Git because it’s only been me caring about said stuff, and also sync things with ownCloud, but there could be something better, esp. wrt versioning and non-geeks.

                      1. 1

                        I’ve not used any of the open source offerings - there are several and Google can help you find them. I’ve used commercial ones though like DocStar and … Oy I can’t remember the name of the other one :)

                        1. 1

                          Dropbox.

                          1. 1

                            I never knew Dropbox does versioning, that’s pretty cool! I should have specified that I’d prefer something self-hosted/OSS but maybe I should look deeper into Dropbox.