Planet SCM

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…

Robert is right about surveys in the UK. But they were “triangulations” and apparently nobody used the term “baseline.” I think that was because baselines were only needed when allocating property that the government was going to hold and sell off. The UK, of course, qualifies as one of those ancient civilizations where every deed was describe using the “10 paces past the frog pond to the tree stump” mechanism.

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.

In the UK there are lots of triangulation points around - little concrete blocks on the tops of hills and elsewhere.

For more details see:

http://www.telegraph.co.uk/travel/main.jhtml?xml=/travel/2004/10/30/ettrigpillars.xml&sSheet=/travel/2004/10/30/ixtrvhome.html

Watching one program in the series he presented, I seem to recall that 30+ sightings were required to avoid error at any one site.

Excellent post. It’s about time some started at the beginning with this subject…