2016-11-07 16:13 GMT+01:00 Nicolas Passerini <npasserini@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