Smalltalk › Pharo › Pharo Smalltalk Users

Iceberg/GitFileTree (was Re: about balkanisation)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

1 message

Thierry Goubier

Iceberg/GitFileTree (was Re: about balkanisation)

Nicolas, I changed the subject, it seems appropriate.

2016-11-07 16:56 GMT+01:00 Nicolas Passerini <[hidden email]>:

2016-11-07 16:26 GMT+01:00 Thierry Goubier <[hidden email]>:

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