1

I have a parent repository A.

I've created a small child repository B of the parent repository containing a cherry-picked small list of sub-folders for access by another team using hg-convert

hg convert A B --filemap filemap.txt

where filemap.txt doesn't do any renaming. It only includes or excludes folders. Such as:

exclude *
include folder1
include folder2/subfolder1
include folder2/subfolder2
include folder2/subfolder3
exclude folder3_that_was_pulled_in_for_some_reason

Converting from A to B works fine. I can also re-run the hg convert command to "push" subsequent changes on A to B (I'm using the term push loosely here...)

But what about when I want to "push" changes from B back to A? Running hg convert B A without the filemap recreates all the commits in B back in A so I have loads of duplicated commits in A.

Is there a reasonable way to keep A and B in sync in future? Is it likely to be impossible if changes are applied to A and B in different orders?

persiflage
  • 1,154
  • 12
  • 22

1 Answers1

2

There's no good way to do this, which is why convert shouldn't be part of a bi-directional workflow. It is possible to use convert incrementally, so you can go A to B many times, but you can't go B to A. You could try to hg export patches from B and hg import them into A, and it would probably work, but when you then hg convert A into B again they'll double up and the merge will probably be hard.

Consider splitting the repo into two separate repos with the public stuff as a sub repository of the whole repo.

/projectname
    stuff.txt
    /folder1
    /folder3_that_was_pulled_in_for_some_reason
    /projectname-public
        /folder2/subfolder1
        /folder2/subfolder2

When projectname-public is a sub-repository, then it can be cloned separately, released separately, and you can take pull requests and patched and merge them in easily.

Subrepos aren't for beginners, but they're easier than round-tripping on convert.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Thanks for the straight answer. Guess my choices are either to reorganize my repo or give up on easy synchronization. Will probably do the latter as synchronizing B back to A is not as high priority as pushing new changes from A to B. – persiflage Oct 12 '13 at 10:36
  • @persiflage, you may regret this decision if the team working on B starts sending you lots of revisions that can't be trivially integrated: Your set-up doesn't have shared version control-- there's one repo for you and one for the other team, and you're tasking yourself with keeping them in sync by external means. – alexis Oct 13 '13 at 11:06
  • @alexis. Thanks, I understand you point. If integrating B's changes back into A was a business priority then I would go with the subrepository approach. In this case the business priority is transmitting the changes in A to B. At the end of the B project, B's changes _might_ be integrated back into A but it's more likely the B project will be orphaned or go in an independent direction. – persiflage Oct 16 '13 at 10:56