monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] git importer


From: Jerome Baum
Subject: [Monotone-devel] git importer
Date: Sun, 12 Jun 2011 15:42:39 +0200

Here are my notes from the wiki:

1. git's fast-export format doesn't carry enough branch information, as
   monotone's branch model is much more information-rich than git's --
   ignoring reflogs for a moment, which aren't used by git-fast-export and
   aren't synced between git repos. In principle the fast-export format
   could carry the information, but it doesn't. reflogs may also not be
   available everywhere, so we'll just have to accept that git is "lossy"
   and find a best solution.

2. The fast-export format doesn't carry unique identifiers per commit, so it
   might make more sense to import directly from the git repo. We loose
   flexibility (e.g. hg --> mtn would have to go through git), but can carry
   over more information (think x-git-commit-id certs).

3. On the other hand, we shouldn't need to worry about duplicate commits as
   the exporter should track that.

4. Just ran another test with git-fast-export. Turns out you can't export a
   subset of a branch (say, the latest commits). Well, you can, but try
   exporting just the tip of your branch: You'll end up with a single commit
   that adds all your files. Basically git-fast-export always assumes the
   first commit to come out of nothing, even if it really doesn't.

   a. Based on this, we really can't work with the fast-export format for
      partial imports, and partial imports would be really nice to have. So
      here's plan B: import directly from git.

In summary, git's internal branch model doesn't retain enough information --
save for reflogs -- so obviously the fast-export format won't exactly be
more informative. We can take advantage of reflogs if we import directly
from the repo. As fast-export doesn't support partial exports anyway, this
looks like the best solution.

I'm thinking of using the plumbing interrogation commands for this. Makes it
much easier than parsing the repo files, and probably easier to adjust later
on if we want to support another VCS.

For branch name mapping, I'm thinking of just using some DB variables or a
simple config file -- the DB variables being preferable for the sake of
partial imports on a regular basis. This is how a first version would work
anyway, and we can improve the UI once we have a working prototype.

Now, I saw the net.venge.monotone.git branch but that looks pretty old and
outdated. I have locally created net.venge.monotone.vsync to start my work.

Happy for any input.

-- 
Jerome Baum
tel +49-1578-8434336
email address@hidden
web www.jeromebaum.com
-- 
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA



reply via email to

[Prev in Thread] Current Thread [Next in Thread]