On 01/29/2016 05:17 PM, Eliot Miranda wrote:
Hi David,
On Jan 29, 2016, at 2:45 PM, David Allouche <[email protected]> wrote:
Thanks Dale for all the explanations.
How Monticello and version control relate in the big picture is starting to
make sense for me.
Now, I better understand why filetree ended up uses a file-per-method format,
even though that is relatively hostile to git user interfaces optimised for
other languages. There is really a need for a file-per-class exchange format,
because that would works a lot better with the existing VCS ecosystem.
I agree so strongly. Class file outs which are eg sorted by selector make much
more sense. They won't hit the file name length limit. They make it trivial
to maintain method and class comment time stamps. They're easier to construct
into snapshots because it's easier to decode the file name.
And then it's easy to add files for package load/unload scripts and for the
history. And then one is much more decoupled from the specific back end. It
could be mercurial just as easily as git.
I think more package-based user interfaces would indeed be a very good idea,
for browsing and for source code management.
Stef, I have the impression you think that git is popular because it is a new
shiny toy. I disagree with this idea. Git is a typical worse-is-better tool.
It's good enough for most people, but it still has many shortcomings. It is
popular in spite of its shortcomings. It became popular as destination for
projects shifting from CVS and Subversion. So it is unlikely to be displaced by
a newer, incrementally shinier tools. Anything that will displace it will have
to provide an improvement of a similar magnitude as the jump between
centralised and distributed version control.
This is a good analysis. What's valuable to the Pharo community is not
displacing an already functional dvcs (Monticello) with an ill-suited one
(git), but in being able to function in ecosystems like github where people can
display their identity and where infrastructure for bug reports etc exist.
Still, I think it's a good idea not to restrict high level models to what git
provides if that's a less than ideal fit to the image model.
Absolutely. Dale's talk of ditching Monticello metadata fills me with
repulsion and makes me want to ask is he trying to sabotage or what?
Eliot, you can't be serious - accusing me of sabotage? Ah, well.... how
about you assume that I'm doing "or what":)
The Monticello metadata in a git repository is redundant and leads to
unnecessary commit conflicts -- end of story ....
Despite the fact that the Monticello metadata is redundant, I have made
sure that the Monticello metadata was included in FileTree from the very
beginning for the very reason that I wanted developers to be able to try
out FileTree, git and github without having to burn any Monticello
bridges .... if they didn't like FileTree, git and github, then they
would be able to back out of their use of git without losing data ...
It seems entirely destructive.
It is not destructive ...
We have a functional package manager which currently supports interchange
between Pharo, Squeak and Cuis,
and GemStone?
I assume that you are talking about Monticello packages and Monticello
repositories ... or what?
I am really not trying to do anything but "invent the future" --- I am
not trying to destroy, I am trying to improve ... If you are not able to
see the shortcomings of Monticello repositories (Note that I am
distinguishing between Monticello packages and Monticello repositories
--- FileTree uses Monticello packages and replaces Monticello
repositories with git) and where git has advantages over Monticello
repositories, then you should continue to use Monticello repositories ...
Personally I don't see Monticello repositories going away anytime soon
and expect to support Monticello repositories in GsDevKit_home, tODE,
and Metacello for the rest of my life:)
Dale
