Re: [Gnu-arch-users] Source Code Managers Carnival

[John Arbash Meinel]

Deliverable Mail wrote:

> I have the following idea: to play with various SCMs and increase
> redundnace of my project, I want to manage it with not one, not two,
> but three SCMs _at once_!  Namely, BitKeeper, Darcs, and Arch.  Since
> only BitKeeper creates a new directory, I do the first import in bk,
> then tla init-tree and darcs init.  Then {bk,tla,darcs} add everything
> in sight, and {bk,tla} commit/darcs record it.
>
> The interesting thing is how to keep them in sync.  My vision is to be
> able to work off any SCM at will, and after a respective commit, to be
> able to push changes everywhere locally and remotely and/or pull and
> pick up in any SCM anywhere.  E.g., I can keep separate directories,
> one per SCM, on every box where I want to do it, and rsync files from
> a common list.  (I'd have to unlock them in bk first; darcs and tla
> win by being non-locking.)
...
The general story that I have heard for managing 2 SCMs (I personally do
arch + CVS) is that you keep a branch in each which is where you merge.
You have a working directory checked out to both on that branch, and
then go from there. In general this branch only exists as a link, which
means that you don't want to get spurious commits to it. Only commits
that are around for the purpose of merging to the other branch. That
keeps your dividing lines clean, and helps prevent you from breaking
something along the way. I think you could overload it for the 3
different scms, though.

For tla it would mean something like having $ARCHIVE/project--merge and
$ARCHIVE/project--main

Then you have multiple directories, a mixed merge, and then probably one
each for bk,tla,and darcs.

I will give the tla workflow, since I know it's commands the best.

cd $tlaworkdir
<hack hack>
tla commit -s "blah"
<hack hack>
tla commit
...

<Okay I am happy, lets merge the projects>
cd $mergedir
tla star-merge $ARCHIVE/project-main
tla changes  # This lets you know what changed, so you know what to bk edit
tla commit -s "Merging the work from tla/project--main"
darcs record -s "Merging the work from tla/project--main"
bk edit ... #The files that changed
bk commit

The biggest advantage of this (I think) is that if you use a branch
*solely* for merging, then you don't have the problem of there being a
bk change in the queue and a tla change, and a darcs change. Where each
one needs to "update" before you can commit. Having a merge branch keeps
it at the identical level in all 3.

I don't really know how bk and darcs handle all of this, but since they
seem to have the idea that "a working directory = a branch", probably
just having the merge directory is enough for them, and you can
push/pull things out of there into your other trees.

John
=:->

signature.asc
Description: OpenPGP digital signature