On 6/28/16 10:22 PM, Thierry Goubier wrote:
Hi Dale,
Le 29/06/2016 01:50, Dale Henrichs a écrit :
Thierry,
Okay ... it is "working" now ... I was also misled by the fact that you
are continuing to fabricate Monticello version numbers which presumably
cannot be relied upon in any way.
Tugrik-Help-DaleHenrichs.11 will show up in each branch that includes
the commit for "Tugrik-Help-DaleHenrichs.10", but the SHA and contents
would be different for each one of the "Tugrik-Help-DaleHenrichs.11" ,
is that right?
Yes.
Perhaps using the short SHA in place of the "version number" would be
safer and provide useful information in the version number slot?
Maybe. But then you'll have a bunch of stuff expecting version numbers
that will stop working.
Ah yes, the nasty Monticello version number parsing that is sprinkled
around the universe... But at the end of the day, these are tools issues
and we shouldn't let tools limitations stand in the way of progress ...
With that said I certainly understand the issues ... The design of
Metacello was almost completely driven by "tools issues" and of course
FileTree was originally written to be completely compatible with the
Monticello tools ...
But by dropping monticello version data (actually making monticello
version data optional) we are breaking the tools ... The fabricated
version numbers that you are currently using do the job of not breaking
the tools, but they break the semantics of Monticello and fool the
developer in believing things that aren't true --- which is a bit
dangerous in my opinion ...
So at the end of the day, if we are really going to _support_ optional
monticello version data, then we need to make a pass through the tools
.... I built tODE from the ground up so that I could make the tools
directly git aware ...
If I support "Metadata" : "false" in GemStone, I do not intend to
fabricate a "realistic looking Monticello version number" ... but I will
look into using the short SHA (when in a git repo) and perhaps fall back
to cypress.1 for non-git repos...
Anyway, I will now be able to move forward with my Metacello Cypress
experiments and also try to understand how Metacello loads are affected
by metadtaless, since you _are_ fabricating Monticello version numbers,
my previous assumptions are not correct ...
Please tell how it goes, especially the part with the short SHA,
because I haven't tried that; I kept creating version numbers to just
have gitfiletree behaving like filetree (apparently).
I understand the motivation ... the basic theory is that when using
Baselines and git, the monticello version number is not relevant any
more ... as you point out above, the SHA will be problematic with
regards to the handful of places in the system that parse package names
to extract a version number and solving that problem by itself may not
be practical -- it remains to be seen ...
The other half of this equation is that new tools should really be built
to work with git-based repositories ... a Metacello Project Browser as
the "main focus" would relieve the pressure to be completely compatible
with the Monticello Browser and open the way for the creation of a
Cypress Browser for working with git/filetree repos...
Dale
