On 6/29/16 6:30 AM, Nicolas Passerini wrote:

Thank you Thierry!

I have more questions inline.

On Wed, Jun 29, 2016 at 10:44 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

All the Monticello GUI : track down version numbers to order stuff in the lists views everywhere.

So, if we built a new GUI which does not rely on those version numbers maybe we could get rid of that problem, what do you think?

The package browser for a git repository does not need to list all versions of the package ... listing a single package name (sans version number and author) is sufficient.

Of course this new tool needs to provide access to the commit log for the repo and then you need to be allowed to do diffs between git versions without respect to packages as well ...

The tool should also provide the git commit log for the package directory (moral equivalent of package history) but then there should also be a way to see the commit history for a class and the methods ...

These are things that I have already done for tODE...

��

The Metacello / Gofer stuff (Configurations, Baselines) also use version numbers.

Yes, I understand that they use version numbers, but do they require that version numbers are correlative?

in Metacello, package version numbers are only relevant in the context of a ConfigurationOf. Only the base package name (sans version number and author) is used in a BaselineOf ... technically ... right now ... Metacello does use the version number when determining whether or not to load a package, but I have a Cypress package extension for Metacello that ignores the package version when loading and this extension will become part of the standard Metacello release in support of metadataless repos ....

Today a ConfigurationOf should not/cannot be used with a metadataless repository, so version numbers on packages is a moot point.

One of the difficulty of switching will be the cohabitation of number-based systems (smalltalkhub) and SHA-based systems, especially when you do things like copying a version from a git repository to a smalltalkhub repository.

I think that currently it is not possible to copy a number-based package version from smalltalkhub to a metadata-less git repository using git file tree. I mean, you can but the new version will not have the same version number, right?

Yes ...

That's why I suggested to change the ordering relation to a partial order based on the property A is an ancestor of B -> B is before A.

I've lost you there. I agree that it is true that A is an ancestor of B -> B is before A, but the most common problem goes the other way arround, i.e. you want to know if A is ancestor of B and the implication then is not true: B is before A 'does not imply' B is ancestor of A. So I missed your point here.

I think that ordering is a moot point for metadata-less repositories ...

There is only one package version present in a checkout of a git repository and it think that it makes sense to turn to explicit git-based tools when dealing with git-based repositories ...

I know that GitFileTree has been aimed at preserving the Monticello-ness of packages, but I think that approach is limiting --- because Monticello itself is limited ---

When I look at a particular commit that I've done with from tODE I not only see the changes that I've made to package, but I also see the changes that I made along the way to other things I've stashed in the git repository like documentation and scripts so to really support the use of git from within the image, we have to start acknowledging that there are artifacts in the git repository that are not just Monticello packages and those artifacts are important to me as a developer to be able to view in the context of the changes that I've made to my code and non-code artifacts ...

For me going metadataless does not imply that "we reconstruct monticello meta data from git" but that "we abandon the Monticello meta data completely" in favor or git-based tools ...

Monticello packages with full metadata will not go away anytime soon, and I am not advocating the abandonment Monticello altogether.

I am advocating that for developers choosing to use git that we build a set of tools that give direct access to git artifacts ...

In tODE I have found that it is possible to provide all of the familiar tools for Monticello packages using a git flavor in parallel with the traditional Monticello metadata-full tools ... at this point in the evolution of Pharo I think that a hybrid approach is called for ..

Dale