1. Aug 27th, 2007

    Dis or Dat (Mercurial and OpenID)

    Embracing: Mercurial.

    All the cool kids are doing it, so I figured there might be something behind it and start playing with it. Let me summarize my first impression of using Mercurial, granted for an early-stage small project with a development team of size N=1:

    I’d hate to go back to SVN.

    The biggest selling point for Mercurial is that it’s a distributed version control system, which quite frankly, I wish someone would explain to me in plain English. What I’m hooked about is how Mercurial does everything right.

    From the little things. It doesn’t version control directories, one of the more annoying SVN features. And it doesn’t spread .svn files all over the working copy, everything goes in one .ht directory at the root.

    To the bigger things. Your working copy is the repository, which means I can commit several times a day, and then when I’m ready synchronize with everyone else. Full version control without the broken trunk syndrome. And Mercurial is all about the changesets.

    In the SVN world you achieve changeset through the delicate act of juggling, either holding on to commits until you’re ready, or painfully branching and merging. None of that complexity indirection. Changesets is what you’re after, and changesets is what you get.

    Which, if it sounds too conceptual, don’t worry about it. The important point to remember is, once you go Mercurial, you’d hate switching back to SVN.

    Giving up: OpenID.

    As you probably heard, a few (headcount) people around the world got to experience the genuine “advantage” of WGA, namely the process by which a glitch on someone else’s computer turns your shiny new PC into the equivalent of a toaster over. Except it’s not even a good toaster over, you wouldn’t want to reheat yesterday’s pizza on its casing.

    It’s not pretty.

    As we all learned from reading SlashdotDigg, this only happens because Microsoft is an evil company. Although the exact technical reason is much more mundane, and does not involve strongly held beliefs in the moral characters of companies. The exact reason is what we often call “single point of failure”.

    Which is something that’s been bugging me — and if you read my posts from before you saw this coming — about OpenID. It’s a single point. And when that single point decides to go on vacation, which happens once in a while, not frequently but just often enough, it takes with it every other service that I OpenID login into.

    So no to that.

    I’m experimenting with OpenID for single sign-on behind the firewall, where both the applications and provider run on the same network, and you can fail-over the providers. Not sure how well that works, there are other problems it doesn’t address. But that much I know, the Web has too many technical challenges for OpenID, so I’m switching my accounts back to username/password.

    Printable PDF | Posted by Assaf Filed in general 9 Comments »

    1. Aug 27th, 2007

      http://technorati.com/people/technorati/ryansking

      About “distributed version control system[s]“, maybe I should put up another post to explain that. I think I have a pretty good grasp on it, but I’ve been using mercurial for about a year, so that not fair. :)

      And about OpenID SPOFs, what I’m working on is getting several identity providers for myself and setting up a chain (on my hompage) of providers I can defer to. This way, for me, the only SPOF is my website, which, well it’d be my fault if it went down anyway.

    2. Aug 27th, 2007

      Assaf

      My OpenID provider happens to be this blog, self-hosting, and although I’m pleased with the uptime (beats Blogger by a few 9’s), it’s still cranky at times.

    3. Aug 27th, 2007

      http://simonwillison.net/

      That’s the reason I believe all OpenID accepting applications should provide a “my OpenID isn’t working” link that does the exact same thing as an “I’ve forgotten my password” link – e-mails you a one-time sign-in token. For added bonus points, applications should let you associate more than one OpenID with your account so if one of your providers goes down you can still log in using a different one.

    4. Aug 27th, 2007

      al3x

      For the record, some of the cool kids are using git. It’s like Mercurial, but faster and more obtuse. It also has a great bridge to Subversion. We have two developers on git and one on svn, and our deploys go out from svn.

    5. Aug 28th, 2007

      Assaf

      @al3x, thanks for the tip. When I looked at Git it felt intimidating, Mercurial had the more familiar face because of the SVN likeness. So it’s interesting to that it’s easy to move between Git and SVN.

      @Simon, I really like the idea of a single-use token, but it has to be part of OpenID, not something that some sites choose to maybe implement in inconsistent ways. A backup identity URL is also something you can bake into the protocol, consumers can query for it when you register and enable all these identities for you.

      But none of these ideas, and none of the criticism on OpenID, is useful unless OpenID embraces them and starts dealing with all these problems. I think there’s a lot of potential, it just needs to happen.

    6. Aug 28th, 2007

      http://simonwillison.net/

      Backup identity URLs are part of XRDS, which is the discovery protocol in OpenID 2.0. I don’t see the e-mail login token as something that belongs in the OpenID protocol (different sites may chose to implement it in different ways, which is why I explain it as an exact equivalent of the “I lost my password” problem) but it certainly needs to be promoted as OpenID best practise.

    7. Aug 29th, 2007

      Joel

      In the beginning, source control was formless and void…

      When Git and Mercurial appeared, attacking pretty much the same problem, you had two user-visible approaches. Linus was after the neat design of the Git internals. The user experience suffered. You had to understand what he was doing to use the tool, but the core was feature complete pretty quick. Mercurial was the opposite. Matt tried to make the user interface dead-simple from day one.

      Today, there’s still a lot of this around. People say Git is hard to use, or that Mercurial lacks this-or-that. Don’t believe the hype. The two systems are pretty much equivalent. If you get the hang of using one, the other isn’t hard to pick up at all.

    8. Aug 29th, 2007

      Assaf

      Question is, what would you use to get more people participating in the project. They’re not all Linus :-)

    9. Aug 29th, 2007

      Joel

      I’m basically saying that either one is quite usable. I personally use Git, as I use it for the kernel anyway. I have friends that prefer Mercurial, and I use it for their projects.

      Your contributors have to get over the hump of a distributed SCM. Which distributed SCM is just syntax.

    Your comment, here ⇓