Antipattern Repository
Thesis: Distributed development, and by extension distributed CM, is the new thing. The notion of a single repository, even as supported by tools like Synergy:DCM and CC:MultiSite, is just not flexible enough. There’s too much “tail” and not enough “dog”. A new model is needed, with support for atomic changes, so that participants in a development network can merge in different orders. DARCS may have some of this. Sun’s Code Manager (?name?) is another example.
Streams is a bad name, because it suggests too much clarity. Maybe bayou? Or currents. Because a developer can move from one “cloud” to another, and take whatever code he is working on in a different direction.
A lot of this sounds like genetics more than anything else. Perhaps code genetics is the right metaphor? Or the code pool?
March 2nd, 2006 at 03:36 UTC
Hmmn – I agree with the distributed development “next big thing” in CM. And a few years ago I thought that the Arch & Bitkeeper way of treating each workspace as a first class repository, with patch-based updates (sort of) was going to be the wave of the future. Not clear yet whether I was wrong on that, or just off by five years in my timing.
But I still want “one repository” for all my lifecycle artifacts. Or, rather, I should really say I want to use the same repository for all of them. Im fine with having distributed repositories, or even the Arch/Bitkeeper model of workspace as a repository. My quarrel is with having to integrate the tools (and corresponding repositories) for by source-code management, requirements management, test management, document management, and models/model management. I want the nice spiffy interface and features of each of those tools, but I sure do wish they could all operate on the same repository. That would be a full lifecycle CMDB.
But I agree that the distributed “thing” is going to be needed too – and with the increased focus on collaboration and innovation over geographical boundaries, it’s a lot easier on branching to use the Arch/Bitkeeper style.
March 9th, 2006 at 06:53 UTC
Think for a moment about what you just said: you want all your stuff using a common repository.
Thing is, all your stuff doesn’t even share a common approach to storage. Blogs and Plogs and Forums are storing their info in databases, source code goes in files, AutoCAD is writing single giant entities (either a megafile or a custom database, your cal).
I think what you really want, and this is probably worth money, is a common repository interface. And I don’t mean WebDAV.
I think it’s some common mechanism for specifying release/branch/time configspecs that gets shared across everywhere.
Part of that almost certainly translates into something implemented at the OS level, for performance. But the rest of it I think has to be worked in to applications. Are you familiar with OS9’s backup mechanism? A virtual directory of datestamps that can be traversed to find a version of a file at some arbitrary timepoint.
That mechanism, or something like it, probably needs to be generalized.
The right place to start, I think, is with a journaling filesystem. After all, that’s how the big storage is implemented, so it’s certainly where implementation will have to go. Beyond that, there’s some kind of mixin technology that permits identifying branches.
I think I’ll post on this, if you don’t beat me to it. Maybe a CMJ article…