SCM Carnival

Greetings -- I've been using bk and trying out arch at the same time,
which led me to darcs).  So now I'm interested in SCM tracking -- the
problem of using two or more SCMs to
manage the same project.  I've posed this problem on gnu-arch-users
and darcs-users lists, and since I mentioned bk, I post it here as
well, hoping for suggestions of topologies and workflows which can
enable multiple distributed SCM tracking, leading to their peaceful
coexistence and healthy redundancy.

I wonder whether there's a mechanism which would allow to update just
the status of internal data, without changing the WC of distributed SCMs.
This way, I'd be able to maintain several SCMs in the same WC, given
they are distributed and non-locking (in RCS ci/co sense).  Since I
can put bitkeeper in that mode via checkout:edit, I now have three
SCMs, arch, darcs and bk, and possibly a fourth, svk (buggy, slow,
and tons of Perl modules), in the same directory.

The workflow on one side is easy: if you change files in WC, all SCMs
will notice it and their commits will record the changes (darcs'
record will commit the changes:) into their {arch}, _darcs/,
BitKeeper/SCCS/ subdirectories.

The problem arises when you update another/remote WC via tla
update/bk|darcs pull.  The first SCM's pull will do the right thing
for that SCM and for the checked-out files.  However, the second and
third, etc., pulls in addition to updating their respective SCMs'
versioning subdirs (is there a special term for them?), will overwrite
the checked-out files again.  It should be harmless, except for the
cases where inodes change and tla tracks them, but looks like it
tracks them only in pristines (?).  In any case, that's why I've come
up with a mirror-star architecture -- you update either the opposite
center (center), or its leaves (leaves), i.e. you can go to the remote
SCMs separately

A1    A2 (leaves)
|    / |
AB1-< AB2 (center)
|    \ |
B1    B2

So, if we change A1 or B1, we propagate the change to AB1 first,
from where the other local SCM pulls it.  Now we have site 1 in sync.
Then, if we pull to the remote AB2 from AB1, we'd have multiple
overwrites.  If we pull into A2 and B2 from AB1 first, we'd at least
be able to check any SCM-specific issues separately.  But to keep site
2 in sync, it's still necessary to push from A2 and B2 to AB2, if we
want to reverse the situation later.

Generally, if one site/SCM is read-only, syncing is easy.  The problem
is when we want a fully symmetric solution -- we want to work on a
desktop and a laptop interchangeably, and keep several distributed
SCMs with full off-line histories locally.  Looks like overwrites of
checked-out files are inevitable with two or more SCMs -- or are they?

Cheers,
Alexy