Forest in mainline?

Florent Guillaume fg at nuxeo.com
Sun Mar 9 19:45:08 CDT 2008


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://...).

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.

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.

What do you think?

Florent

-- 
Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87





More information about the Mercurial-devel mailing list