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.goub...@gmail.com <mailto:thierry.goub...@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
