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

[Deliverable Mail]

I set up a star architecture for SCMC (Source Control Manager
Carnival) as follows:

A1----------A2     (1)
|                  |
AB1---------AB2   (2)
|                  |
B1-----------B2

A is Arch, B is BitkKeeper, and there's a Darcs in third dimension,
similar, so AB1 is a center of a star.

Now, 1 is for a local system and 2 is for a remote.  All repos are
synchronized. The way to do it as I see is to first sync locally --
work in any ray of the star; finish, commit, and sync into the center.
 There, push into the remaining local rays, and to the remote center. 
Remotely, pull from the center into the rays.  So, don't do (1); only
do (2) for local-remote sync.

The center has subdirectories BitKeeper/, SCCS/, _darcs/, and {arch}. 
I create it by doing a bk clone, then copying over .arch-ids/ subdirs
from an arch ray, and copying over _darcs/ subdir from a darcs ray
(and adjusting _darcs/prefs{defaultrepo,repos}).  Arch complains about
the pristine tree changing inodes, have to manually delete it -- is
there an automatic way?  Also, bk reverted to old-days SCCS/RCS
locking and the normal state is read-only.  Any difference, and tla
reports long lists of -- changed permissions.  Is there a way to make
it ignore such metadata change, so I don't have to commit just that?

Overall, I wonder whether this star setup is something people have
used, and what other ones are possible.  E.g., could you sync as (1)
and then propagate into the center, etc., -- what are possible
protocols, advantages/disadvantages, etc.

Cheers,
Alexy


On Thu, 17 Mar 2005 19:45:33 -0600, John Arbash Meinel
<address@hidden> wrote:
> 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
> =:->
> 
> 
>