CODEWITHSUNDEEP
version-controlmercurial
user488551
user488551

Reputation: 406

Making a subset of a repository publicly available, whilst keeping history

I've got some code under version control (using mercurial), and would like to share some of it, whilst hiding other parts which I cannot release into the public domain (at least at this stage).

I'd ideally like to keep the revision history of the public code intact, and, more importantly, be able push/pull changes between the public repository and the repository containing both public and private code. It should not, however, be possible to recover any of the private info from the public repository history.

From what I've gleaned so far, it should be possible to extract the public stuff using hg convert with a filemap and excludes, although this would change all the revision ids and preclude any interaction between the two repositories.

For completeness I guess I should add that the repository was originally converted from cvs.

Would be grateful for any ideas,

Upvotes: 2

Views: 112

Answers (2)

anton.burger
anton.burger

Reputation: 5706

If you can use subrepos, that's probably the best way to go, but using convert need not preclude interaction between the pieces. If the public and private stuff is completely disjoint, use convert to split the original repo into two completely disjoint subsets (regenerating all changeset IDs), then recreate your "superset" repo by cloning one and pulling the other (using --force to overcome hg's objection to unrelated repositories). You'll end up with a slightly unconventional repo which has two parent-less changesets and two heads. Merge the heads and you have a unified view of public and private again, with the public repo's ancestry effectively on a branch of its own.

Upvotes: 0

VonC
VonC

Reputation: 1326782

It is not always practical, but if the public part of your repo can be limited (or move to) to a subdirectory of your current repo, then you could:

  • extract (with for instance, like you mentioned, hg convert) that subdirectory in a repo of its own
  • reference that new repo as a subrepo for your main repo.

You would then manage two repos:

  • one public (with only the public files in it)
  • one private (with a reference to the public repos as a subrepo)

Upvotes: 3

Related Questions