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?
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.