Create a new repository starting with tip?

[Giorgos Keramidas]

On Wed, 17 Feb 2010 21:40:21 -0500, greg fenton <greg.fenton at gmail.com> wrote:
> We have a large, mature code base internally.  We have recently
> refactored it heavily and are now looking to share the head branch
> (and forward) with some partners.  We cannot want to expose
> pre-refactoring (pre-tip) histories to those partners.
>
> Is it possible to clone a repository (or create a new one) starting
> with "tip" and continue to push updates to that clone while allowing
> our internal repository(ies) to continue to grow (i.e. maintenance
> mode on older branches, new development on tip) ?
>
> Thanks in advance,
> greg.fenton

Not through the normal 'hg push' machinery, because the new repository
is "unrelated" to the old one.  What you can do is: create a new clone
with a snapshot of the original sources:

    % cd /work/mainclone
    % hg archive -t files -r tip /work/exportableclone
    % hg id -r tip
    REV tip

    % cd /work/exportableclone
    % hg init
    % hg commit -Am "Import project FOO at REV"

I would probably keep two separate clones or this sort of thing:

  * The main internal clone that has full history and is actively being
    developed by people who are allowed access to the full history and
    the full set of repository files

  * An 'exportable' clone that is ok to give to partners.  Redacted
    history and careful review of what files are pushed to the external
    clone would be the norm for this one.

This unfortunately creates more work for your side, because you will
have to carefully review what is pushed to the 'exportable' clone and
then also review the work of partners before it is copied back from the
exportable clone to your main branch.

You can use the transplant extension and plain "hg export" to copy
changesets from either direction of this scheme to the other one.

The extra work of transferring patches between two unrelated clones is
unfortunately unavoidable, but you can use the opportunity to install a
review process that guards against common partner-related problems,
like: (1) licensing of exported code, (2) licensing of partner-generated
content, (3) to limit the amount of history the partners can see (by
squashing multiple changesets from the main branch before importing them
to the exportable branch), (4) to limit the number and type of files the
partner repository receives, etc.