Forest Extension - Not to be found?

[Mohan Pakkurti]

>>> It broke with 1.8 and is broken again with 1.9. Each breakage creates pains
>>> for multiple people and it is just a pain in my view.
>>> 
>>> Hopefully we will have a better alternative than a shell script soon, and when
>>> that happens I'll re-adjust the Dev Guide to use that extension, although I do think
>>> the Dev Guide spent too much time talking about forests than it should have.
>>> Most developers work in one repository, and I think the guide should try and focus on that.
>>> 
>>> -kto
>>> 
>> 
>> Honestly, to Kelly's point, I would say that forest should not be a
>> mandatory feature, and although the script is less nice that the forest
>> extension, the fact that this breaks from time to time is indeed
>> irritating, especially since mercurial is released quite often, and we
>> only maintain it for some very specific version of hg (usually the
>> latest, as this is what we get from the Linux distributions we Free
>> Software hippies tend to use), so we leave out all the other people that
>> for one reason or another don't updated.
>> 
>> I still think we should support forests, but not to the point to make
>> them mandatory and spend so much words in the documentation, especially
>> (and this was the point of the original post), since our links are
>> outdated. Well, that's just my point of view, that is :)
>> 
> 
> Not only does it break regularly as it's not part of the upstream Mercurial project,
> but the forest extension is slow.  I moved away from it in preference of my own shell
> scripts while it still worked and to no apparent disadvantage.  Exactly what is the
> benefit of it?
> 

There is no benefit. No one has gotten around to owning and supporting a proper replacement for the forest extension and we need that functionality because of the way the repositories are organized and relate to each other. 

Alternatives to the forest extension  (subrepos) have been discussed and they usually end up in heated exchanges. 

We could gain a lot by revisiting the design of our repositories and workflows so that we can continue to work as we do today and in addition allow elementary operations, like tracking changes to the entire collection of repositories. 

I would support such an effort, instead of periodically having to address issues caused by using a deprecated feature in the source control system.

>> Cheers,
>> Mario
> 
> -- 
> Andrew :)
> 
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Support Free Java!
> Contribute to GNU Classpath and IcedTea
> http://www.gnu.org/software/classpath
> http://icedtea.classpath.org
> PGP Key: F5862A37 (https://keys.indymedia.org/)
> Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37