Forest in mainline?

[Matt Mackall]

On Mon, 2008-03-10 at 01:45 +0100, Florent Guillaume wrote:
> On 10 Mar 2008, at 01:20, Matt Mackall wrote:
> > On Wed, 2008-02-20 at 22:29 +0100, Florent Guillaume wrote:
> >> Are there plans to put forest.py in the mainline to have it in the  
> >> 1.0
> >> release? I'd really like that, this extension is very helpful.
> >
> > [catching up with old mail]
> >
> > For that to happen, we need the maintainer to push it. Probably too  
> > late for 1.0 at this point.
> 
> 
> Here's an abridged proposal for a simpler forest-like behavior for  
> mainline. I can code it in stride in the next two days if it seems to  
> fit the bill.
>
> Basicall, we would add a ".hgsubrepos" special file to the root of the  
> working directory. It would contain a series of lines of the form
> 
>      foo = http://hg.example.com/foo#experimental
>      bar/gee = http://hg.example.com/gee#stable
> (or another suitable format if spaces in the directory names are  
> deemed important, maybe [foo] \n path = http://...).

But it's not sufficient to simply have the repo URL, you also need the
cset identifier to check out. And in this era of too many SCMs, perhaps
an SCM type too. We probably want to keep the cset ids separate from the
type/source info because the latter is user-editable while the former is
managed by hg.

> 1. clone
> 
> hg clone does a normal clone, then consults the .hgsubrepos of the tip  
> (or of the default branch?) and clones
> each of the repositories described there.
> 
> 2. pull
> 
> hg pull does a normal pull, then consults the working  
> directory .hgsubrepos and recurses in each directory there.
> If -u is specified, then the newly-updated .hgsubrepos is used.
> 
> 3. push
> Similar to pull.

Except when it isn't. We'll often pull from a different URL than we push
to.

> 4. update
> hg update does a normal update, then consults the updated .hgsubrepos  
> and recurses in each directory there.
> Update could warn if the current working directory branch is different  
> than the #rev specified in the pull URL, if applicable.
> 
> The directories foo and bar/gee have to be relative paths. If a  
> leading subdirectory (like bar) doesn't exist in the working  
> directory, it is ignored when recursing. A #rev can be added like usual.
> 
> That would fit the two main use cases I have:
> - be able to clone several repositories in one go, including a branch  
> specifier (that could differ between the various subrepositories),
> - be able to pull/update several repositories in one go.
> Also it allows "recursive" forests; if foo has a .hgsubrepos it would  
> be itself taken into account.
> 
> This could be enabled by default, or could be enabled only if some  
> flag is present in hgrc. I don't see a problem in allowing it by  
> default.
> 
> The various commands could take a -S / --no-subrepos flag to  
> disable .hgsubrepos recursing.

You forgot commit, which is perhaps the most interesting operation.

-- 
Mathematics is the supreme nostalgia of our time.