hg convert splice for nested repositories

Benoît Allard benoit at aeteurope.nl
Wed Sep 24 06:06:27 CDT 2008


Kurt Granroth wrote:
> What, exactly, does the --splice option do in 'hg convert'?  Could it be
> used to consolidate multiple smaller repositories in one large one?
> 
> Here's an example:  I work on quite a few projects that make pervasive
> use of cvs aliases.  Pretty much all projects look like this:
> 
> myapp toplevel &sharedlib &project/one &project/two
> 
> The checkout, then, looks like:
> 
> myapp -- sharedlib
>      +-- project --- one
>                 +--- two
> 
> I am trying to convert all that into one 'myapp' hg repository.  Yes,
> forests would make more sense but that's a looooong other topic.  Right
> now, I'm testing out a "fat" repository.
> 

What I would do is the following:
Convert the existing repositories so that the paths to the file share 
the same root (`one` to `myapp/project/one` for instance). This can be 
done by converting with a <<rename>> directive in the mapfile.

Then once you have your four repository sharing the same root path, a 
"push/pull" with the --force parameter will put all of them together. 
That will create a head for each repository, merging shouldn't be a 
trouble as the should touch different files.

Finally, you can reconvert (hg -> hg) the resulting repository (maybe 
with the --datesort parameter) to  make it looks more shiny.

About your original question and the "slicemap" parameter, I see it more 
like a way to modify the parents of some changeset within the same 
repository. But hopefully someone can comment more about that one.

Benoit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4197 bytes
Desc: S/MIME Cryptographic Signature
Url : http://selenic.com/pipermail/mercurial/attachments/20080924/9cae1666/attachment.bin 


More information about the Mercurial mailing list