Thierry,
Very good points and I agree with all of them ...
Regarding a Smalltalk-based merge tool, I've written a git mergetool for
tODE (consider it a prototype) that could be adapted/ported for Pharo ....
My thoughts regarding the MC issues ... Fyou make good points some of
the "internal bugs" in MC and I think that it is important to point out
that the "internal bugs" you are referring to only affect Monticello
with regards to its repository functionality and not its package
functionality .
My inclination is to move forward and create a new, simpler package
model (Cypress is a good name) that is used with disk-based repos ...
the new package model would be protocol compatible with MC so that
definition-based snapshot comparisons continue. The new package model
would only be used for loading and there could/should be facilities for
converting between MC and this new package model.
FileTree would continue to be MC based and Cypress would be able to read
FileTree and FileTree would be able to read Cypress.
The improvements and changes that we are discussing (many of which
require a fair amount of implementation work) would be done in Cypress ...
The rationale is that Monticello packages encompass both the repository
and the code/definitions and for disk-based scms, Cypress would only
need to worry about the code/definitions --- and would make it possible
to move away from the version number-based package names that aren't
necessary when the underlying scm is doing the versioning without
affecting the MC implementation ....
Of course, if a new Cypress package model were introduced, the tools
would need to change, but since we are already considering changing
tools, this would be the perfect time to improve the underlying model
for disk-based SCMs.
Dale
On 2/3/16 1:13 AM, Thierry Goubier wrote:
I went through all the different possible file formats, class-based,
package-based, method-based, log metadata and the like, and I
concluded that:
- the method based format is as good as any other.
- method based format allow for method-history queries on the git/vcs
history (as well as class based / package based queries).
- the tree structure on github or bitbucket is quite convenient (and
browsable) to the point one could edit a package directly in it (I do
when I need to do a quick fix).
- anything that can compress a bit the metadata version is probably
good to consider. version files can be huge.
- merge drivers really work and releave us from conflict resolution
- we need a merge tool written in Smalltalk/MC
- MC version numbering is a very bad idea
- MC almost never using properly UUIDs is a very bad behavior
- MC packages history can be considered broken in the general case
- it takes time to define, implement, test and really use a new format
and tooling
