Reusing deleted sub-repo directory in parent repo

Mike Williams obsd1 at eandem.co.uk
Mon Jan 24 11:22:35 CST 2011


Hi,

This may be a bit of an old ball scenario but here goes.

My company is looking to move from their current proprietary SCM (a 
topic for an email thread another day) to another, and are of course 
considering Mercurial.  The current system has a flexible variation on 
sub-repos and we are looking into whether hg supports what we want, or 
at least are used to.

One of the processes being looked at is where a sub-repo has been 
removed and its files put into the parent repo.  Essentially folding the 
sub-repo contents into the parent repo.  The question was how this 
change appears to other developers when they pull from the master repo?

So I whipped up a test script to mimic the effect of a developer folding 
in the sub-repo's contents, pushing to the master repo, and another 
developer then pulling from the master repo.  The result was not quite 
what I had expected.  Following is annotated output from running the 
commands in bat file.

First creation of a parent repo with a sub-repo.

F:\temp\sr>hg init a
F:\temp\sr>echo a  1>a\a
F:\temp\sr>hg add a
adding a\a
F:\temp\sr>hg commit -m "Root" a
F:\temp\sr>hg init a\b
F:\temp\sr>echo b  1>a\b\b
F:\temp\sr>hg add a\b
adding a\b\b
F:\temp\sr>hg commit -m "Sub" a\b
F:\temp\sr>echo b = b  1>a\.hgsub
F:\temp\sr>hg add a
adding a\.hgsub
F:\temp\sr>hg commit -m "Add sub" a
committing subrepository b

Next create two clones from it, one to modify and another to pick up the 
changes via the master repo.

F:\temp\sr>hg clone a a-clone
updating to branch default
pulling subrepo b from F:\temp\sr\a\b
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
F:\temp\sr>hg clone a another-clone
updating to branch default
pulling subrepo b from F:\temp\sr\a\b
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

Next the sub-repo is folded back into the parent repo by updating .hgsub 
and removing the .hg dir for the sub-repo so the parent repo sees the 
former sub-repo's directory.  This is then pushed back to the master repo.

F:\temp\sr>echo #  1>a-clone\.hgsub
F:\temp\sr>hg commit -m "Remove sub" a-clone
F:\temp\sr>rem remove .hg for it to work
F:\temp\sr>rmdir /s/q a-clone\b\.hg
F:\temp\sr>hg add a-clone\b\b
F:\temp\sr>hg commit -m "Sub to file" a-clone
F:\temp\sr>hg push -R a-clone
pushing to f:\temp\sr\a
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 3 changes to 3 files

Here is the fun - the second clone pulls the changes and tries to update.

F:\temp\sr>hg pull -R another-clone -u
pulling from f:\temp\sr\a
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 3 changes to 3 files
abort: path 'b/b' is inside repo 'b'

The blunderbus solution of blowing away the original sub-repo dir solves 
the problem but feels wrong.

F:\temp\sr>rmdir /s/q another-clone\b
F:\temp\sr>hg update -R another-clone
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
F:\temp\sr>dir /b another-clone\b
b

So is this the way things are with folding sub-repos back into the 
parent?  Is there a better way to handle this scenario?  Or is this a 
missing bit in sub-repo support to be filled at some future date?

I am expecting some push back on folding sub-repos back in in the first 
place.  Being able to work this way means that the build system does not 
have to be changed to cope with changing directory names (such as 
folding back the sub-repo content into a dir with a different name).

Sorry for the long posting.

TTFN

-- 
Mike



More information about the Mercurial mailing list