Can changesets in mercurial repositories be merged chronologically?

I'd like to re-use code from project A in project B (both in separate repositories), so I'd like to move several files from the original project repository A to a common repository C which will be used by project B. (dependencies managed by Maven, etc.)

I can extract just the files I want to move from A into their own 'filtered' repository F using the convert extension and some additional scripts (to discover the complete history of said files).

At this stage I could: a) pull F into C, merge and commit, or b) export all of F changes as patches then import them into C However both approaches lead to a repository C whose changesets are not chronologically ordered. I see the history of F prepended to the history of C.

Is it possible to 'merge' two repositories such t开发者_StackOverflow中文版hat the changesets are ordered chronologically?

I have scripts to do this - but so far, I've had to completely rebuild C each time I move a different set F from A. (By exporting all C and F as patches, creating a new C, then importing all the patches in chronological order).

Thanks!

Not really. The parent of a changeset is built-into its nodeid (which is a cryptographic hash), so you can't reorder the actual parentage of changesets without completely altering/rebuilding them.

You can bring changesets into a repository in any order you want provided that the changeset's parent changeset precedes it.

So if A and B have the following changesets with the following revision numbers (r=) and creation times (t=):

A: null----[A r=0,t=0]----[C r=1,t=2]----[E r=2,t=4]
B: null----[B r=0,t=1]----[D r=1,t=3]----[F r=2,t=5]

You could, with careful pulling create a repository like this:

C: null----[A r=0,t=0]-------------------[C r=2,t=2]-------------------------[E r=4,t=4]
     \
      \-----------------[B r=1,t=1]--------------------[D r=3,t=3]------------------[F r=5,t=5]

There's, however little value in doing that as the sequence number of the changeset (r above) is meaningless).

Ideally your repository B would be a clone of A with all of its local modifications existing only in B. That way if you fix a bug in A you can pull into B and then merge to get that fix. Transplant/convert is a hollow substitute. Another option is to have the common parts of A and B extracted out into repo C which both A and B would then use as a Mercurial subrepository.