Create a new repository starting with tip?

[Giorgos Keramidas]

On Wed, 17 Feb 2010 22:08:18 -0500, greg fenton <greg.fenton at gmail.com> wrote:
> Thanks for that, but from what I gather by your response you are
> saying that we essentially cannot maintain the histories going forward
> for the external repository?

Precisely.  The main reason why I mentioned two repositories is that you
*cannot* pull & push between two unrelated repositories without exposing
the history of both to each other.

Technically it _is_ possible to pull from two unrelated repositories in
the same hg clone.  But you end up with two disjoint history graphs like
this example:

                           tip
    o --- o --- o --- o --- o

                      o --- o

You can then commit a synthetic 'merge' that joins the two histories:

    o --- o --- o --- o --- o --.
                                 `+ tip
                      o --- o ---'

but the main problem, namely that *both* historry DAGs are visible in
plain sight, is still there.  I don't think that's a good idea for all
the reasons we've already mentioned about licensing, history visibility,
and so on.

> I am hoping that the external repository can begin gathering revisions
> starting from its creation and going forward.

This cannot be done with pull.  The transplant, or MQ+rebase can help a
bit though.  See below.

> The concern over licensing, etc. is one reason for the refactoring
> effort.  Procedures are in place now to ensure that all checkins going
> forward on the tip/trunk and future branches from there will be fine
> to share with others (i.e. we have full rights to share).
>
> We want to be "fully open" with the code from this point forward,
> "future histories" and all.  But our internal developers still want
> full historical access on the internal repository for maintenance.

I see.  Transferring patches between two trees is not easy without the
pull & merge backend of hg.  But you can probably do something similar
to what the Solaris folks did to ease things a log:

  * Import a snapshot of the internal 'tip' to a new repository.  No
    previous history is visible but all the files are there.

  * If there are closed binaries that you cannot open yet, tweak the
    build glue of the open/external repository to use pre-built
    snapshots of these binaries from a configurable place, e.g. by
    setting FOO_CLOSED_BIN="/opt/fooclosed".

    Then you can keep releasing binary drops of "fooclosed" so that
    people working with the open repository can still build everything.

  * Move the main development to the new repository.  This way the
    internal developers will work 'normally' with the new source tree
    and will be able to quickly spot bugs that open users would hit
    anyway; fixing them earlier rather than later will benefit both
    sides of the world.

A "mostly linear" history of the external repository is also something
that can help a lot with patch transfer when you do have to backport
changes from the new, open repository to the old one.

You can use the MQ and rebase extensions as part of the normal "commit
process" for all changes in the open repository.  Then it's slightly
easier to extract all the relevant bits of a commit from the open
repository when you have to backport them to the internal closed tree;
you just have to run

    hg export --git REV > /tmp/patchfile

and apply the patch to a clone of the internal repository (fixing any
conflicts that may arise before pushing to the main internal clone).

Fixing the conflicts may not be straight-forward for *any* changeset,
but it is currently unavoidable AFAIK.