Forest

[Florent Guillaume]

Bryan O'Sullivan wrote:
> On Feb 28, 2008, at 2:34 PM, Thomas Arendsen Hein wrote:
> 
>> * Florent Guillaume <fg at nuxeo.com> [20080228 01:46]:
>>> I'm considering integrating the forest extension directly into the
>>> main hg commands, so that for instance you can "hg pull" and if  
>>> forest
>>> is enabled it would do the equivalent of current "hg fpull".
>> This is a good idea.
> 
> I agree.  The need for something like Subversion's externals facility  
> is rather huge.  However, I never found the time to use forest, as I  
> was always put off by its large command set, so I don't have a picture  
> of how this would work in practice.
> 
> Rather than run off and start hacking, I think that something like  
> this is important enough to have a picture and discussion of how it  
> ought to work beforehand.  Is the model used by forest actually  
> appropriate?
> 
> For example, commands currently take pains to avoid crossing repo  
> boundaries.  If I'm in a parent repository, and I run "hg add subrepo/ 
> foo", what should happen?

It should abort like today I think.

> If I run "clone" against a remote
> repository that's a forest, how does it discover that the remote repo  
> has subrepositories?

In the same way it does this already, by doing a recursive "walk" to 
find .hg directories. This needs the forest extension to be enabled on 
the remote side.

> How do I clone *just* a parent repository?

I propose a -F flag to force not using forests even if the forest 
extension is enabled.

> As you can see, there are lots of questions to answer, and this is  
> just the result of about 90 seconds of thought, nothing deep.  It  
> wouldn't do to just slap the forest command semantics into the core.

I agree. I believe only the clone/pull/push-related operations should 
take forests into account. It would be:
clone
incoming
outgoing
pull
push
Current forest.py also applies to the following, which should be discussed:
status (not a big problem I think)
fetch
update

The current forest.py finds the forest by walking subdirectories (I 
think this walk should be bounded by default btw). It does not attempt 
to find the "root" of the forest by going upwards, but I think this 
would be helpful to have. It would allow pull/pushing from anywhere in 
the workspace. This could be enabled only if some flag is set in some 
.hgrc somewhere.

Current forest.py also has to option of passing a "snapfile" to the 
f-commands; this file is a "detached" description of the forest (the 
list of repos that make the forest). I think it may be useful to have 
this for clone but I don't see the big attraction for other commands.

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