Nicolas, I changed the subject, it seems appropriate. 2016-11-07 16:56 GMT+01:00 Nicolas Passerini <npasser...@gmail.com>:
> > 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. > What you're saying is that you are using the same trick as GitFileTree does, but you have performance issues, which means... we're not talking about exactly the same thing :) (and trust me, my development machine is on the "very" slow end for the Pharo community, so I'm sensitive to performance issues). > > 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. > Agreed. But you will allways create some sort of MCVersionInfo / MCAncestry to be able to represent the start of this inside your system... Subtypes of MCVersionInfo do work fine there. Just have a nice, correct API call that allow you to compare two versions. (Little trick used in GitFileTree: all ancestry based on a specific commitID is shared among all the versions with it as an ancestor, in memory). Weak version info will take care of cleaning the unneeded stuff anyway. > > 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. > As long as you don't track commits for which the package has no version, then that seems perfectly fine. > > 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. > I never specify a commitish, I use the GUI or Metacello (and since I'm using baselines, Metacello doesn't uses version numbers except to compare with what is inside the image). GitFileTree only uses commitish to load a version... it just happens to be able to also convert version numbers to a commitish if it is presented with a version number. The attention to version numbering is a thing of people using too much ConfigurationOf, and those people are living in the past. Thierry
