CODEWITHSUNDEEP
mercurial
jdowdell
jdowdell

Reputation: 1638

How to make mercurial (hg) outer repositories ignore the existence of inner (non-sub) repositories

In short, how can I make an outer mercurial repository entirely ignorant of a given inner repository's existence? I essentially just want to ignore the presence of certain .hg* in subfolders, and let the outer repository carry on its happy way.

Put another way, I would like to have two mercurial repositories that have nothing to do with each other, but just happen to track the same file. Yes - edits to that file have to be committed twice, etc.; but in this case that's what I want.

Background:

I am in the process of side-stepping mercurial's inability to handle partial clones, with something which is hackish but which I believe will work. We have a huge project tree checked into mercurial, and a contractor needs access to a portion of this tree. My understanding of the subrepository approach is that it's difficult to back-hack into an existing tree; and anyway I wouldn't want to force this on all my coworkers just so I can collaborate with one contractor.

What I would like to do is create inner repositories inside one or two folders in a clone of our whole project tree. I plan to then further clone those inner repositories out to the contractor. It's not the best, but it would work; after he pushes to me, I can merge into the files touched by the inner repositories, and then walk out to the outer repository to check into our overall tree. Ideally, from the outer repository's perspective, it would seem that some magic just updated some files.

The problem is that mercurial seems to know too much about itself :). For instance, things were going along alright with an hg init, hg add *, and hg clone; but when he added a new file on his end and I went to hg add that in the outter repository, I get (obfuscated):

abort: path 'foo/bar.txt' is inside repo 'foo'

I can get around it by renaming the inner repository's .hg to something else, but in general this approach is getting out of hand. There's also trouble with hg stat ignoring the inner repository; and other commands and other things I'm trying to do from the outer repository keep breaking in general (I'm having a ton of trouble with a subrepository sitting inside one of the folders I shared with the contractor).

Any ideas?

(I did come up with one theoretical solution: creating another repository baz/ somewhere else on my file system, and then using file system symlinking to pull over the folders from the original tree. But then I'm hard-wired to a given machine to bridge the two repositories, and I'm worried this approach has other consequences I'm not thinking of. Would just be more convenient to cloak the inner repos from the outer's perspective.)

Thanks!

Upvotes: 3

Views: 296

Answers (1)

Mark Tolonen
Mark Tolonen

Reputation: 178379

I don't think there is a way to do what you want, but it isn't too hard to turn a subdirectory into a subrepository. The only caveat it is easier to go back and forth between pre- and post-split history by giving the directory a new name once it is a subrepository.

For this example I have the following directory structure and I faked a bit of history for each file:

org
 + file1
 + dir
    + file2

Step 1 - Enable the convert extension.
Step 2 - Create a filemap to move dir history to the root of its own repository. Example:

include dir
rename dir .

Step 3 - Run convert, creating a directory with a different name. Step 4 - Move the new directory under the original project.
Step 5 - Remove the old directory from the original project.
Step 6 - In the new subrepository, update to the latest version.
Step 7 - In the original repository, add an .hgsub file referencing the new subrepository.
Step 8 - Add the .hgsub file, fix up any project paths that referenced the old directory and commit.

Example:

hg convert --filemap filemap org sub
move sub org
cd org
hg remove dir
cd sub
hg update tip
cd ..
echo sub=sub >> .hgsub
REM Fix up other project paths referencing dir->sub.
hg ci -Am "Converted 'dir' to repo 'sub'."

Now you have maintained history for your contractor, and can update to older or newer versions of the main history without conflict. When you update to before sub exists, Mercurial correctly updates sub to the null parent and dir will appear in the history. Update to the tip of history, dir disappears and sub updates.

Upvotes: 2

Related Questions