Hopefully you won't mind that I'm adding the git list back to the cc
line, since it would be useful for others to provide some feedback.


Actually, there *is* an hg-fast-import.  It exists in the hg sources
in contrib/convert-repo, and it is being used in production to do
incremental conversion from the Linux kernel git tree to an hg tree.
So it does handle octopus merges already (it has to, the ACPI folks

So actually I have thought about this a fair amount, so if you don't
mind my pontificating a bit.   :-)

At the highest architectural viewpoint, there are three levels of
difficulty of SCM conversions:

A) One-way conversion utilities.  Examples of this would be the
	hg2git, hg-fast-import scripts that convert from hg to git,
	and the convert-repo script which will convert from git to hg.

B) Single point bidrectional conversion.  At this level, the hg/git
	gateway will run on a single machine, and with a state file,
	can recognize new git changesets, and create a functionally
	equivalent hg changeset and commit it to the hg repository,
	and can also recognize new hg changeset, and create a
	functionaly equivalent git changeset, and commit it to the git
	repository.  

C) Multisite bidirectional conversion.  At this level, multiple users
	be gatewaying between the two DSCM systems, and as long as
	they are using the same configuration parameters (more on this
	in a moment), if user A converts changeset from hg to git, and
	that changeset is passed along via git to user B, who then
	running the birectional gateway program, converts it back from
	git to hg, the hg changeset is identical so that hg recognizes
	is the same changeset when it gets propgated back to user A.

(C) would be the ideal, given the distributed nature of hg and git.
It is also the most difficult, because it means that we need to be
able to do a lossless, one-to-one conversion of a Changeset.  It is
also somewhat at odds with doing author mapping and signed-off-by
parsing, since that could prevent ...
[ message continues ]

Hi,



I know convert-repo and like it as a starting point. But it has some 
problems like not properly creating hg branches, can import only one 
branch at a time which must also be checkout out on the git side, etc.

With 'hg-fast-import' I meant something like git-fast-import where 
clients can feed in more raw data instead of preparing each commit on 
its own and comitting it.


The small numbers are the hg revision numbers which we'll need for 
git-fast-import. Ideally git-fast-import would allow us to use anything 
for a mark we want as long as it's unique. But I'm sure there's a cheap 
way of mapping revision to SHA1 in the hg API.

So, if anybody wants to join in writing up such a hybrid system, I'm for 
it. :)

   bye, Rocco
-- 
-

[ message continues ]

I wrote something like that for fromcvs: <http://ww2.fs.ei.tum.de/~coreco=
de/hg/fromcvs?f=3D7992019d6861;file=3Dtohg.py>

it still communicates blobs via files, because that's what hg wants to se=
e.  performance is quite okay.

cheers
  simon

--=20
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low =E2=82=AC=E2=82=AC=E2=82=AC NOW!1  +++=
      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

[ message continues ]

Well, just to set the record straight...

So yes, I did a 12-way merge in the kernel a long while back on a lark.
I don't generally do them any more in the official kernel tree
because I think they make bisect more complicated than it needs to be.

cheers,
-Len
-

[ message continues ]