2016-11-07 16:26 GMT+01:00 Thierry Goubier <thierry.goub...@gmail.com>:
> >> The problem I found is that in order to recreate sequential numbers, you >> have to load all commits into the image. >> > > Why? GitFileTree doesn't need to do that at all! Well, you know the code: > it just ask git log to rebuild the parent / child relations for a package > directory, and that is all... Then, like a mcz, the package isn't loaded > into the image unless you select it in the GUI. So why did you need to load > all the commits? > > Well, at the beginning, I was trying to read all the filetree metadata > stored in the repository to build the versions as if it was mczs... and > that was a really bad idea (slow parser for version files, hundred of files > to scan, many files were even unreadable/broken by conflicts leftovers in > the filetree repository). > Yes you are right, I expressed myself badly. You don't have to load "the commits". But, you still have to create an MCVersionInfo for each version of the package in the repository. In fact... you can create them, it will not kill you, but I think that this structure is not so useful, because it is always faster to use log/revwalk to ask about the relationship between two versions/commits. Moreover, we do not want to think about packages too much, we prefer to think in terms of a whole project, so the most interesting concept for us is the commit and not the version. Therefore, when I build a history (sometimes I do) I create a graph of commits and not a graph of versions. Finally, this leads to that, even in the case you want to load a specific version of a specific pacakge (which is not the normal case for Iceberg), you would specify a commitish (+ a package name) and not a version name.
