On 01/28/2016 12:34 AM, Sven Van Caekenberghe wrote:
On 28 Jan 2016, at 09:23, Christophe Demarey <[email protected]>
wrote:
I read too fast.
But my comment is still true.
We also want a new version browser. Monticello browser is too tied to ...
Monticello. We would like a better approach for both git and monticello.
It is totally wrong to put Git and Monticello at the same level, they are
related but different things.
Monticello models our code and your changes to it. It also has a way of putting
a package into a persistent representation that can be copied around. An MC
server is nothing more than storage.
Filetree is another way of doing that, using a different representation, but it
still needs MC for the high level stuff. Git is versioned storage. And there is
a conflict there, yes.
But throwing away the MC code and changes model would leave you with file outs.
You do not want to go there, really. Never, ever.
Sven,
If you look at my presentation on "Practical Git for Smalltalk"[1] from
2012, I take pains to differentiate between the Monticello package model
(definitions and snapshots) and the Monticello repository model (mcz files).
Noone is proposing to throw away the Monticello package model (to my
knowledge).
So in these discussions about supporting git we are talking about a
model where Filetree is still being used for Monticello packages on top
of a git storage strata ...
I have brought up the point about a "Metacello Project Browser" because
both git-based and mcz-based projects can benefit from a higher level of
management:
- commit all dirty packages, then update and commit the
ConfigurationOf for mcz-based projects, OR
- save all dirty packages and perform a git commit for git-based projects
- perform a diff on all dirty packages in a project ...
- etc.
Dale
[1]
http://www.stic.st/wp-content/conferences/2012/Wednesday/1415-Practical_Git_for_Smalltalk-Henrichs.pdf
