Cleaning up a mercurial repository for an external

Question

I have an active project with some sensitive files and directories. I want to hire an external contractor to do some simple UI work. However, I don't want the contractor to have access to some directories and files. My project is in mercurial on Bitbucket.

What is the best way to clean up the project and give him access to commit his changes? I thought about forking into a new repository, but I am worried about removing directories I don't want him to have access to.

How to I remove them so they don't appear the original changesets? How to I merge his repo back without it removing those directories in my main repository? Is a fork the way to go?

Answer 1

Naturally a repository needs access to its whole history in order to self-check its integrity. I don't know of a way to selectively hide parts of the repository (there's the ACL extension, but it is for write access only).

In your case, I would

1. create a new repository where all sensitive information has been stripped off (use the convert extension for that task).
2. Then I would let the external guy work with that repository.
3. Once his work is finsihed, pull his repository into a clone of the original one (using -f to force pulling of an unrelated repository), and
4. rebase his first changeset and all its children onto a head of your original repository.
5. Finally, push the rebased head to the original repository.

For steps 3 to 5 you don't necessarily have to wait until the external developer is done. Rebasing intermediate states of his repository is also possible.

Yet, it's an theoretical idea .. one has to see how it performs in practice.

Alternative: In case you frequently have external contractors who shouldn't see some parts of your code, I would second @Anton's comment to setup permission related multiple repositories.

Answer 2

There are multiple ways to do this:

1. Using sub-repositories
2. Using multiple repositories
3. ???

Regardless, you need to restructure and split your existing repository, so this will create havoc if you have lots of people working on this project, they will all need to stop working, synchronize their work, destroy their local clones and clone down fresh copies after the restructuring.

One way using multiple repositories would be that you do the following:

1. Make 2 extra clones of the repository (keep one around for fallback if everything fails, you can always go back)
2. The first clone you need to run the hg convert command on to get rid of all the bits and pieces your contractor should not access
3. Then you fix that repository so that it works by itself. You might have to change code to provide hooks and events for anything not present but which you intend to inject into the project before you build
4. Then you need to run hg convert on the other clone to get rid of everything now present in the first.
5. Then you pull from the first (contractor) repository into the second (private) repository, merge, and do necessary fix-ups so that the code still works as intended

What you have now is two repositories:

1. Contractor-repository, with only the bits you want to expose
2. A private repository, that has pulled and merged from the contractor-repository, and contains all the other bits and pieces

From now on, whenever the contractor has pushed work to his repository, you need to pull from it and into the private repository and then merge.

Your repositories would look like this:

Contractor:  ---97---98---99---100---102---103---104

                                               M                 M
Private:     ---91---92---93---94---95---96---101---105---106---107
                                             /                 /
                                            /                 /
                       ---97---98---99---100---102---103---104

The two changesets with M above are merge-changesets that merge contractor-supplied code into your private repository.

Note that you too would have to commit code to the contractor-repository, to work on and fix bugs in the code there, but all the private bits you can keep private.