Comments

  1. Thursday, June 12, 2008 2:54:46 PM by Jonathan Allen
    Nothing in this article addresses the real reasons people hesitate to use a DVCS. For example, centralized security and access restrictions. Or strong links to bug tracking systems.

    All you did was repeat the marketing material for DVCS's strong points.
  2. Thursday, June 12, 2008 3:09:20 PM by MB
    you should make the article into a pdf, it's quiet long.
  3. Thursday, June 12, 2008 3:30:38 PM by David Goodlad
    Jonathan Allen: He did mention centralized security ("authorization"). Yes, a developer is free to change any file in his local repository, but for any of those changes to make it into the hypothetical 'central' repo it has to be pushed there. With a central repo in the dvcs model you can still implement authorization and rules at that point...

    For an example of a bug tracking system working nicely with git (another DVCS), check out Lighthouse (http://www.lighthouseapp.com) and Github (http://www.github.com). Github acts as a kind of 'central hub' for my projects, and I have it automatically tell lighthouse about any changesets that I push to it. I can format my commit messages to reference specific bugs in lighthouse, and it all works quite nicely.
  4. Thursday, June 12, 2008 3:49:37 PM by Root
    What the hell is DVCS? ALWAYS-ALWAYS give a definition for you acronyms at least one at the head of an article.

    I knew what it meant but many who might stumble across this article through one of the MANY social bookmark sites. Who knows you might actually inspire someone rather than keep them guessing what the hell you're talking about.
  5. Thursday, June 12, 2008 4:37:18 PM by charles
    Great content, thanks!
  6. Thursday, June 12, 2008 4:43:55 PM by Yann
    Great article!

    I've managed to sell the day-job (a smallish startup company) on the use of Git. Its working out very well for us, despite having over half of the workstations being Windows (we use Cygwin-git atm).
  7. Thursday, June 12, 2008 5:40:59 PM by Troy
    I've never seen issues with a DVCS and centralized security. Every implementation I've seen allows for access rules and controls - it's just common sense to have access controls.

    Control freaks may not like that an individual developer can checkin a branch on his own workstation - centralized repositories have lead to the notion a commit is somehow sacred, requiring a lead developer to sign off on the commit, etc. Many tyrranical developers don't like the idea of anybody being able to do a "commit" without his express permission.

    This actually hurts productivity. What a DVCS does is allow a developer to commit early & often, providing more checkpoints in history to roll back to. It's a security blanket for an individual developer to know his code is "checked in" somewhere, and then those changes can be reviewed and merged with the master repository with as stringent security controls as any other VCS.
  8. Thursday, June 12, 2008 5:44:35 PM by heyroot
    @#4 check the first line
  9. Friday, June 13, 2008 2:45:17 AM by Greg M
    We keep a huge history of art assets, large undiffable files - every minor tweak is stored as a separate copy of that large file. Although we desire some of its other advantages, DVCS can only work for us if artists can regularly and easily purge (to a certain age) their local history (since it's safely committed upstream) for selected files or directories. And of course programmers will only want the very latest version of each art assets. I'd be very interested to hear what facilities are out there in the various DVCS implementations.
  10. Friday, June 13, 2008 8:39:24 PM by Anonymous
    All of the "pros" I've heard about DVCS seem to point back to "working remotely" - I can't fit this into the way I work because every company I've worked for in a decade of software development and consulting gigs has had very strict requirements that the source code to their apps never be taken off authorized company resources - I couldn't work on the code on the bus or at the coffee shop even if I were so inclined.

    If your business requires a centralized development model, and the source code is never allowed off-site, is there value in using a DVCS? If so, what is it?
  11. Saturday, June 14, 2008 1:46:33 PM by David Terrell
    Just comparing the DVCSes I've used to svn and CVS, they do merges and branches so much better it's not even funny. SVN, in particular, is terrible at merging between branches -- you completely lose original authorship and metadata.
  12. Thursday, June 26, 2008 4:55:31 AM by james lorenzen
    I would love to switch straight from svn to a dvcs such as mercurial. However, coworkers might disagree, but I liked your myth buster #1. I do have one question though: if you treat a dvcs like a centralized system, who is responsible for committing changes into the central server? The whole team? On large teams do you need dedicated people who are responsible for submodules that do nothing but commit patches?
  13. Thursday, June 26, 2008 6:01:13 PM by Ryan
    Re: the person who said the "pros" only amount to "working remotely", that's really not it at all. Like the poster after you said, the real win for me is decent merge support. I've had too many years of wasted time with CVS and SVN doing things that literally take seconds in Mercurial.

    I'm so glad we switched to Mercurial here at work 2 years ago -- and for the record, almost nobody is using it for remote development. 99% of work happens on site.
  14. Saturday, June 28, 2008 9:50:01 PM by Jakub Narebski
    @Jonathan Allen: there are distributed bugtrackers (Ditz, TicGit, Bugs Everywhere), and there is support for distributed version control systems in traditional bugtrackers / issue trackers (Trac, Lighthouse, Launchpad). As to ACLs: see #4

    @Greg M: Git (one of DVCS, used for Linux kernel) has good support for binary files; the problem of course is merging. As to "purging history" (to limit size of 'current work' repositories): they can re-clone main repository using so-called "shallow clone", i.e. clone only part of history (this has some limitations, which could perhaps be lifted if there is "an itch"). Alternatively they can share some parts of storage using alternates mechanism, if there is possible to have some shared network filesystem folder (it only needs to be read-only for all developers). Dana How worked hard on better support for large binary files in Git: search git mailing list archives and read her posts.

    *Ad restricting access*: while it is possible also using distributed version control systems (DVCS), e.g. using ACL extension/plugin in Mercurial, or update-paranoid example hook or Gitosis tool for Git, Karl Fogel in "Producing Open Source Software" (producingoss) wrote that he found restricting access by tool (technically) rather by convention and culture (socially) detrimental; this might be true also for non-OSS development.

    *Ad fad*: ate last one company, BitMover, Inc. has made proprietary distributed version control system, BitKeeper, and it exists to this day (or at least seems to). BTW. using BitKeeper for Linux kernel, and later revoking free license, is what spurned creation of Git and Mercurial (and at least indirectly improvements in Bazaar-NG).

    @David Terrell: upcoming Subversion 1.5 will have better support for merging. It will still be centralized SCM...
  15. Sunday, August 31, 2008 8:04:02 PM by G
    Good article.

    But to me, none of this matters to the point of argument; in 10 years the pendulum will swing back. Or be broken altogether.

    Remember when PC's meant having applications and computing power all to yourself, instead of a dumb terminal? (Well, probably not the dude with *TEN WHOLE YEARS* of "programming gigs"). Guess what? Now it's all about having a thin client presentation layer with centralized application and processing allowing ease of maintenance...ie, a dumb terminal. Sounds a bit like a mainframe?

    As for working on the beach...when you hit your 40's you might realize there's more to life than work, and that blogging about work is NOT a hobby.

    Then again, what am I doing but elliptically arguing about it at 42? :-P

    Peace.
  16. Wednesday, December 26, 2012 10:53:11 PM by Quinton
    One thing concerning DVCSs that I have to ask is why choose Mercurial over Git?
  17. Friday, November 01, 2013 9:40:16 AM by ku-isi blog
    thanks
Add Comment