2016-11-07 16:13 GMT+01:00 Nicolas Passerini <npasser...@gmail.com>: > > I started creating version names using the unix date (the number of > seconds since 1970), which allows me to provide version numbers without > complex calculations and without breaking Monticello. > > Numbers are not nice but we do not use them any way, it is just to comply > with Monticello requirements. >
There is a human effect to them (I like to see the numbers increasing as I add new versions, of course!) but, well, since Dale said working with .1 would work, so it is :) Git short commit ID are only convenient for long-time git experts. > >> >>> 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... >> > > I am using git log extensively, turns out to be a very powerful tool. > Libgit provides a very similar tool called revwalk ( > https://libgit2.github.com/libgit2/#HEAD/group/revwalk). So in each case > Pharo does not have to do those performance sensitive computing. > Yes! Problem solved. > > 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). Thierry
