2016-11-07 15:42 GMT+01:00 Nicolas Passerini <npasser...@gmail.com>: > > 2016-11-07 15:30 GMT+01:00 Thierry Goubier <thierry.goub...@gmail.com>: > >> Thierry, If I'm not mistaken, Esteban is referring to the fact that in >>> FileTree we are still using Monticello to do the load of the packages and >>> even when we are running metadataless, we end creating fake meta data to >>> simulate an mcz ... you and I have had conversations about ways to >>> eliminate this "requirement" because it is meaningless in a git context ... >>> >> >> Yes, this I understood. I do believe that what I suggested at one point >> (have the ability to compare versions with an 'isAncestorOf') would be very >> nice for that transition (work in mcz as well as on git with/without >> metadata). >> > > I would like to listen to your ideas about this topic, but I am not sure > it is possible to achieve that compatibility. In fact we tried to do it for > Iceberg and at some point we decided to abort it. >
I have an idea where such comparisons are done. I'd simply start by changing version numbers to the short commit ID, and see where it breaks ... > On one side, trying to re-create monticello sequential file numbers in git > is simply not possible, at least in a reliable way. On the other side, > loading the graph of package versions and dependencies is really slow for > big repositories (such as pharo-core), once we removed that requirement > Iceberg got like 100x faster. > Yes, this is performance sensitive code. I spent a significant amount of time trying to optimize the smalltalk part of that in gitfiletree a few years ago... before I was shown that it could only scale to ~ 1000 commits (with a repository that had more than 8000 different versions for a package). Delegating everything to `git log` solved the issue. No code duplication! Overall, this is something that has worried me since the beginning of libgit. Libgit is low level and pushes some of the processing into Pharo, which is not the best tool to do high-speed processing of tree structures. And then, instead of designing the best solution to our problem, you end up trying to get the best design that doesn't hit a performance issue... Thierry
