[PATCH RFC] subrepo: Add the '--thin' option to pull a thin strand of changes

[Alistair Bell]

On May 17, 2011, at 5:00 AM, Martin Geisler wrote:

> Alistair Bell <alistair.bell at netronome.com> writes:
> 
>> # HG changeset patch
>> # User Alistair Bell <alistair.bell at netronome.com>
>> # Date 1305575046 14400
>> # Node ID 4d759579fb076f37cdf99d84ff59ceffeaefcf2a
>> # Parent  85c82ebc96a3611890b716f2ca5534cb92c6dbd5
>> subrepo: Add the '--thin' option to pull a thin strand of changes.
>> 
>> The idea of 'hg pull -r' or 'hg clone -r' is to pull a partial history
>> of the repo. An example may be to pull only those changes that are
>> asserted to be 'good' from a 'dirty' repo to a 'clean' repo. Use of
>> '--thin' extends this functionality to subrepos. With 'hg update
>> --thin' or 'hg pull -r <rev> -u --thin' only the good data is pulled
>> from subrepos, and other history is left alone.
> 
> The concept of abandoned heads gives you a general way of marking
> changesets as good and bad: mark the bad changesets as abandoned. The
> changesets will then no longer be pulled or cloned.
> 
>  https://bitbucket.org/mg/abandoned-changesets/

In the case we're using, the 'dirty' changesets aren't abandoned. They simply haven't been regressed (or submitted for regression) yet. Maybe they will be in the future, maybe they won't, but our workflow is for users to pull from the 'clean' repo, push to the 'dirty' repo, and inform the regression engine of a changeset ID. The engine will then pull that changeset and its history from the 'dirty' repo into a local copy of the 'clean' repo for regression and publishing to the central 'clean' repo. So any heads found in the 'clean' repo are assumed clean.

The further wrinkle is that we have a whole lot of top-level repos, each of which uses a different subset of our subrepos (we have about 90 subrepos), so some form of auto-integration is needed to take 'clean' code from one configuration of subrepos and see if it's clean in another. That means that we have to assume all heads in the 'clean' repo are actually clean, which they aren't if the entirety of each subrepo is pulled from 'dirty'. Hence the need to add thin subrepos.

If you have a better idea of how to accomplish this, I'm all ears.

A.