Maintaining a project with several SCM (including bzr)

[John Arbash Meinel]

Matthieu Moy wrote:
> Hi,
> 
> For the development of DVC (http://wiki.gnuarch.org/xtla#DVC), we have
> several backends (curently GNU Arch, bzr and mercurial). We'd like to
> develop each back-end with the tool for which it is designed (i.e.
> manage Bazaar 1 support using Bazaar 1, bzr support with bzr and so
> on). Currently, I'm a bit frustrated to use Bazaar 1 to develop a
> Bazaar 2-related tool. If we want to invite, for example, Darcs people
> to develop a Darcs back-end, we clearly don't want to force them to
> use our SCM (whether it's GNU Arch or another one).
> 
> AAUI, bzr can import Bazaar 1 archives relatively well, but this is a
> one-time and one-way conversion. If ForeignBranch get implemented,
> then we can keep the mainline as a GNU Arch archive, and let bzr users
> access it with bzr. But this doesn't solve the problem in the general
> case.

Well, it isn't a two-way conversion, but I wanted to mention that it
isn't a one-time conversion either.
baz-import is smart enough to be able to add new entries into the
conversion. So if you have a pristine conversion, and new entries are
added to the Arch archive, you can just pull those over by restarting
the command.

It could be upgraded to some sort of two-way by putting certain extra
information into headers. So if you had a "arch/bzr" branch, it would
pull new changes from another branch, one at a time, and then commit to
both making sure to match the headers.
Monotone has an interesting property that you can add new information
about a revision at any time. Neither Arch, nor bzr support modifying
headers after they have been committed. But with monotone, you could add
the "this revision corresponds to Arch revision X, and bzr revision Y".
Annotating revisions is an interesting idea, and might be something
worth investigating, though it leads you to the idea of revisioning the
annotations about revisions....

> 
> One option is to have the developer of the mainline use all the tools,
> in the same tree, and commit with each of them each time. For example,
> 
> $ <hack hack hack>
> # or "baz merge foo at bar.com/...", or "bzr merge http://..."
> $ baz commit -m "message"
> $ bzr commit -m "message"
> $ hg  commit -m "message"
> ...
> 
> But 1) this is painfull and 2) it doesn't solve the merge history
> problem. The project will have a different merge history in each SCM.
> 
> Another option is to make nested trees for each back-ends, and to use
> the appropriate tool for each subtree. But we still have to chose a
> tool to manage the core of DVC. That can be bzr or Darcs, which are
> both easy to use and to set up (no dedicated server). The problem is
> that this means making at least 3 subtrees, for a project which is
> still relatively small (4 operations to get a fresh copy or to update
> a < 1Mb project).
> 
> 
> That's not a crucial issue, but I'd like your advice on the cleanest
> way to manage this situation. Most of all, I think the experience of a
> multi-scm project can be fun! The question "I want to contribute to
> the project X, but I surely don't want to use their brain-damaged SCM"
> is becoming more common ...

I know there is Tailor, which is the darcs developed project, which lets
you one-time convert between many different scm backends.
If possible, it might make sense to upgrade tailor so that it can
support on-going conversion. I haven't used it much myself, so I don't
know if it handles recording merges, but that certainly gets tricky if
you were trying to convert the various histories.

It would be interesting to set up a system which would do all of these
conversions, but I think ultimately one of the SCMs is either going to
be the master, or you are going to have a bunch of oddly recorded merges
(darcs says this was merged from here, bzr says this other merge
occurred, etc).

> The question "I want to contribute to
> the project X, but I surely don't want to use their brain-damaged SCM"
> is becoming more common ...

You can always contribute to a project without using an SCM. :)

> 
> Thanks for your advices,
> 

Sorry I don't have more of a solution.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051111/e744ce97/attachment.pgp