Le 01/12/2014 20:25, Dale Henrichs a écrit :
On Mon, Dec 1, 2014 at 10:39 AM, Thierry Goubier
<[email protected] <mailto:[email protected]>> wrote:
Le 01/12/2014 19:21, Esteban Lorenzano a écrit :
also, in a point (not now, but eventually)… we will need to drop
something. The idea of keeping anything ad eternum just does not
scales.
But it's a good way of delaying git integration in the Pharo
platform by having to redesign the file format as well.
Thierry,
Not sure if you are being sarcastic here:)
I wish I was :(
I just don't see how the current FileTree format "delays git integration
in the Pharo platform."
This is exactly my point. It works, it is cross-platform (mcz to
FileTree and back), it has a significant bug squashing done, it's stable.
Yes, it's not perfect. Metadata is noisy in github output, it used to
cause problem when merging, and there is issues with very long path and
file names.
However, all discussions about changing the file format around Pharo
brings no convincing arguments... just cosmetic changes, which basically
says: lets do the same as before, but not compatible and with a new code
base so that we can have our own new bugs.
(If I had to redesign the file format for git use, I'd consider FileOut
with a better parser, and alphabetical ordering: minimal code for
reading and writing. But I'd loose some of the features that tODE has
when querying the git logs).
I consider git integrated into tODE and tODE uses FileTree.
Perhaps it's a matter of approach. In tODE the git support is NOT
centered on the package browser ... the git support is built into the
"system browser" so you can look at git history from a class, method OR
package perspective ... Other perspectives are possible as it is
relatively straightforward to pull up the git history of any directory
or file ... and git integration should include the ability to view diffs
and merge non-smalltalk files...
I agree. But you are at the point where you just say:
"libgit2 or GitFileTree are just means to an end: better tools to tap in
the power of git and do something interesting with it."
Look the situation of Pharo... They are still trying to get the
infrastructure working. Yes, libgit2 will be better than GitFileTree,
but barely, and how many years will Pharo have invested for that? In the
mean time, what should I invest in? A GitFileTree which will be wasted
anyway? And in a few years time, will NativeBoost still be in use? Or
replaced by FFI and LowCode? With libgit2 reimplemented? With no support
of libgit2 on ARM?
And for what? The goal is to hide git behind any package and source
management tools we have in the image, after all.
A package is just one of the artifacts that is stored in a git
repository. Monticello packages have Monticello characteristics ...
Cypress packages without Monticello meta data[1] are another package
format and they have slightly different characteristics than Monticello
packages and they are equally supported by tODE. [To be fair the Cypress
package support is still experimental but a year ago I was doing active
development using tODE and Cypress packages in conjunction with
Monticello packages].
FileTree intentionally supports Monticello-style packages so that the
FileTree packages can leverage the existing Monticello-based tools like
Metacello (I had to extend Metacello to support Cypress-based packages)
or the Monticello Browser.
So at the end of the day, I think that git integration for Pharo depends
upon a broader approach to integrating git-based tools throughout the
tool eco-system.
Once you start looking at a chunk of versioned disk as containing more
than just Smalltalk source code there a numerous possibilities for
building in-image tool support for distributing, sharing and maintaining
documentation, workspaces, plugins, deployment scripts, etc. way beyond
the limitations of a package ...
Yes, this is it: that focus is interesting. That's why I refer to tODE
when I say you are showing us the way on git. But Pharo is a long way
from being that ambitious.
Thierry
