-
Georges Racinet authored
In the case of the hashed storage, we keep a subset of the directory hierarchy for namespaces and the repo HGRC includes from that, hence depending on the namespace path from the storage root and the depth of the hashed storage (currently a constant, at two intermediate subdirectories). In both the hashed and non-hashed cases, this is provided by `relative_path_from`, whose result is just `../../hgrc` in the non hashed case. The inclusion path is relative to the storage root, hence this independent of the storage location, which can change (reconfig, change of host by backup & restore) with no need to crawl through repositories. This partially defeats one of the advantages of the hash storage: avoiding too much top level directories. This shouldn't be critical for Heptapod because 1. By the time we have instances that big that this cluttering is a problem, assuming we just don't use a FS with hashmap directories (XFS for instance), we'll be able to come up with other mechanisms 2. It's about namespaces having either HGRC settings or subgroups. These should be the minority. After all, using subgroups reduces the number of toplevel groups.
3c0b374e853d