Forest

[Peter Arrenbrecht]

On Sun, Mar 2, 2008 at 4:09 PM, Mark Williamson
<mark.williamson at cl.cam.ac.uk> wrote:
> > What is notable is that in both these forests, all the (non-root) trees
>  > are direct subdirectories of the root. I would hazard a guess that for
>  > _most_ forests, all trees are either direct subdirs of the root, or at
>  > least direct subdirs of other trees. If that is true, then the forest
>  > walk could be made much faster if by default it only did a one-level
>  > check beneath already-known trees. There could be an option to enable
>  > slower full search in case you really had a forest such as
>  >
>  > root
>  > root/windows/i386
>  > root/windows/ia64
>  > root/linux/i386
>  > root/linux/ia64
>  >
>  > with no repositories "root/windows" or "root/linux".
>
>  I'd go further and suggest by default only caring about subrepositories that
>  have been explicitly added.  e.g. have a (revision controlled) subrepos file,
>  which records what subrepos we care about.
>
>  This is basically the same model that we already have with files: unless the
>  users has explicitly added them, or requested a slow path operation, we don't
>  check for things we don't know about.  I'd suggest it's going to be very rare
>  that we really need to implicitly check that new repositories have been added
>  to the forest, since I can't imagine that being frequent in most use cases.
>
>  This is more-or-less similar to the way git subprojects work, which is a
>  similar setup but integrated into the git core.  I'm not sure it's as nice as
>  forest in many ways but it does have certain advantages.

I'm not a forest user, but on the face of it this sounds reasonable to
me. However, would this be recursive, like if a/.hgsubrepos contains
subs/b and a/subs/b/.hgsubrepos contains c would a/subs/b/c be
tracked?
-peo