Comments

  1. Wednesday, May 14, 2008 5:37:08 PM by Tom Fakes
    The cool Rails kids are using Git
  2. Wednesday, May 14, 2008 5:37:47 PM by Tom Fakes
    The cool Rails kids are using Git
  3. Wednesday, May 14, 2008 5:38:44 PM by Tom Fakes
    Ooh, these comments with captcha suck
  4. Thursday, May 15, 2008 7:30:33 PM by Will
    tl;dr, tell me when the cliff notes are ready.

    I actually use a DVCS for my smaller personal projects; its called fileshare. Branch and merge are a bitch, and forget about history...
  5. Monday, May 19, 2008 5:18:26 AM by Chris Hahn
    Great write-up, I was laughing almost the whole way through!
  6. Tuesday, May 20, 2008 8:24:46 PM by Matt Doar
    "What?", said Bob, "three days! where was the standby server, ready for recovering from the backup? You did take backups, right?"


    "Oh, kind of, and we always meant to get around to a standby server" confessed Alice with a toss of her head, "but, anyway, now our build machines each have a complete repository on them, so we use them for releases."

    "How do you choose which one?" asked Bob.

    "The one that we used last time" smiled Alice, impishly.

    "Wait a minute, hold on now." said Bob, "I've just remembered. What about access control? How do I stop just anyone changing the code?"

    "Well, whichever machine we declare to be the server for holy. blessed builds that we release, we're really careful about who is allowed to merge changesets to it."

    "Really careful? I want a bit more than that" humphed Bob.

    "Ok, we have the usual authentication using SSH against our LDAP server and then we do authorization based on file paths in the changesets."

    "Sounds better; I guess you do know what you're doing. But does the authorization stay with each cloned repository?"

    "Er, we're working on that." admitted Alice, "but once it does, we'll be able to move our official release repository to any machine we like."

    "Groovy!" said Bob, glad he had been able to add to the story of DVCS.
  7. Tuesday, May 20, 2008 11:13:19 PM by John
    Alice, stunned by the turn of events, thanked Bob for his time. She knew the transition to DVCS was inevitable and was happy to see that Bob and his team would get a productive head start. Always a student of humanity, the level of resistance she encountered was immense yet the conversations were illuminating.
  8. Wednesday, May 21, 2008 2:26:48 PM by A
    I think more use cases for the offline access might help -
    You are demoing some middleware to a customer and need to make many fixes / changes at his place. You still can have your version control with you! Not all companies will allow offsite access to the version control server. Further even within a company many times some locations cannot access the version control or its extremely slow.
  9. Wednesday, May 21, 2008 7:09:30 PM by Jack9
    The biggest problem with Version control is merging time, not downtime. More DVCS nonsense.
  10. Thursday, June 12, 2008 6:49:42 PM by John Stracke
    Bob had only once heard of cellphones in 1990? What hole was he living in? By 1990, they were showing up on TV (I remember a pocketable one on LA Law), and car phones were going for one penny plus contract.
  11. Saturday, June 14, 2008 11:56:40 PM by Aaron
    Jack9, have you used a DVCS? If not, you're as bad as "Bob"; blind and ignorant and unaware. Go try hg. It's not as slick and fast as bitkeeper, but it sure beats svn, cvs, p4, etc. Every time I have to go back to a centralized system, I'm depressed.
  12. Saturday, June 28, 2008 8:38:39 PM by Jakub Narebski
    While "one branch per repository" (or "repository / clone is branch") workflow is default Mercurial workflow, distributed version control systems of now (for example Git, but this includes Mercurial with localbranches extension) can use "multiple branches in repository" workflow. This workflow has grown at demand of users (as you can read for example in blog of Junio C Hamano, current git maintainer).

    One issue of note is that while push based workflows are not that different from first glance from centralized SCM workflow (but for the backups, commit then merge, developing feature in multiple commits on topic branch, off-line commits, etc.), pull [request] based workflow require having project maintainer (like Linus Torvalds for Linux kernel, or Junio C Hamano for git itself; he/she does need to do all the work if he/she sets up "network of trust" Linus Torvalds was talking about in his Git Talk at Google Tech Talk). But if you read old but (in some) good "The Mythical Man-Month" having maintainer for a project is one of recommendations, I think one that survived passage of time.
  13. Saturday, June 28, 2008 8:41:54 PM by Jakub Narebski
    > "The biggest problem with version control is merging time, not downtime. More DVCS nonsense."

    @Jack9: with distributed version control systems you can commit, _then_ merge when you have time to resolve it; heck, you can ask somebody else to resolve merge in his/her repository if you are not able to do it for some reason (Linus does it sometimes, by the way).
  14. Saturday, June 28, 2008 11:06:40 PM by Jakub Narebski
    > "The biggest problem with version control is merging time, not downtime. More DVCS nonsense."

    @Jack9: An alternative to merge (well, not exactly aternative, more like alternate workflow) is something that is called "rebase" in Git, "transplant" in Mercurial, and "graft" in Bazaar. See for example http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

    Git has also additional feature making repeated merging easier, namely git-rerere (reuse recorded resolution of conflicted merges). This tool records how did you resolved merge so you don't have to repeatedly do the same resolving. As far as I know this feature is unique to Git. Lately there was talk on git mailing list about extending feature list of git-rerere, among others deleting resolutions and enabling sharing recorded resolutions...
  15. Friday, July 25, 2008 6:45:07 PM by Tristan
    "Sounds better; I guess you do know what you're doing. But does the authorization stay with each cloned repository?"

    "No, does your centralised system stop a developer from making changes to parts of his/her checked-out files? No, so I guess stopping changes to a set of files you're not going to use for releases isn't even theoretically possible. Bit odd to require it of the DVCS and not the centralised system."
  16. Wednesday, October 27, 2010 10:47:20 PM by Criação de Sites
    Version control is always a good discussion.
  17. Friday, November 01, 2013 9:41:00 AM by ku-isi blog
    thanks great site
Add Comment