Create a new repository starting with tip?

[greg fenton]

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?

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

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.

Thanks,
greg.fenton
--
greg.fenton ^_at_^ gmail (yes, dot com)



On Wed, Feb 17, 2010 at 21:55, Giorgos Keramidas
<keramida at ceid.upatras.gr> wrote:
> 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.
>
>