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