[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

the report from PyCon

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-02-28 02:37:33 CET

So I went to PyCon in Dallas last thursday-sunday, along with Fitz and
a bunch of other Googlers. Fitz gave a great 30-minute talk on the
history of cvs2svn.py, and I gave a goofy 5-minute lightning talk
about some IRC bots I've been writing. All in all, very much a fun
conference.

From the version control world, both Martin Pool (of bazaar-ng) and
Bram Cohen (of codeville (and bittorrent)) were in attendance. Martin
gave an interesting talk on bazzar-ng, and Bram was interviewed as
part of sunday morning's keynote presentation.

I spent time chatting with both of them, but mostly with Bram. (After
the fact, this seems odd. I later heard rumors that Bram really hates
Subversion. Yet he was quite friendly with me!)

Anyway, here are the summarized tidbits of information I'd like to
relay:

  * As you would expect, the distributed version control world is
    still mostly a bunch of small systems written by 1 or 2 people,
    with very few users. They reason they're not all that popular yet
    is because hey're all still experimenting with the Really Hard
    Problem of how to get merging done "right" when repositories are
    connected and merged in an essentially random, unpredictable
    graph. It's hard to track every line's history, and even harder
    not to be confused during a merge when there are multiple
    ancestors and repeated merges hide around every corner. Zillions
    of crazy edge cases, I'm told.

  * Bazaar-NG really seems to have it's stuff together, though. It's
    quite well done, very professional, and seems useable. It seems
    to be leading the pack.

     * In Martin's talk, he described a feature whereby a set of users
       can "bind" their local repositories together to emulate a
       centralized version control system. In other words, it would
       prevent me from committing to my private repository, because
       some other person has committed a newer version to his own
       private repository. It forces a set of users to merge in
       lock-step, rather than work separately for a long time and
       merge everything later on. Really fascinating!

  * Bram claims to have done a "dissertation's worth" of research into
    the really hard problem of merging in a distributed system.

      * He claims to have gone back to 'first principles' about how
        the 'Weave' format is meant to work (back when it first
        started being used in SCCS files 30 years ago), only he thinks
        he's found a much better, more useful way to store
        line-history in a weave format.

      * He's developed a new merging algorithm called the "codeville
        precise merge", which he thinks is The Solution. You provide
        the algorithm with a list of ancestors, the history points
        where they came from, the ability to retrieve ancestors' text
        as needed, and a snapshot of the current file. It then merges
        changes into your file, and doesn't mess up where other
        algorithms do.

      * A description of the algorithm is up on the revctrl.org wiki,
        as well as a fully working python implementation.

      * Bram is busy rewriting codeville around this algorithm, and
        apparently some other systems are starting to adopt it now.
        (Monotone? I think...)

      * Perhaps we should look at it too, it may be a key component in
        our merge-tracking feature. If we like the algorithm, or find
        that the SCM community in general validates it as The One,
        then it will also influence the way in which we choose to
        represent (and store) line-based history.

      * Bram also told me about the way in which codeville does
        authentication, and how he's invented a novel system for
        that. I forget what it's called though. It's not like he's
        gone and invented something that isn't already in Bruce
        Schneier's book, but the novelty comes from some interesting
        use or sequence of pre-existing techniques. He heavily
        recommends we take a look at it, that it's much better than
        svnserve's CRAM-MD5.

That's the news from the field.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 28 02:37:59 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.