Hi Ben,
Le 03/02/2016 06:00, Ben Coman a écrit :>
I'm curious how the merge driver is implemented. I think it was
mentioned that git calls-back to Pharo to do the processing. Is this
it something like this...
* How to make Git preserve specific files while merging
https://medium.com/@porteneuve/how-to-make-git-preserve-specific-files-while-merging-18c92343826b#.raovdvj9p
Probably, haven't read it.
* A few of my Git tricks, tips and workflows
section under gitattribute(5)
http://nuclearsquid.com/writings/git-tricks-tips-workflows/
Yes. You use git attributes to trigger the use of a pharo-implemented
command line tool which does the merge for git.
Or... rather than the metadata being a specific file (e.g.
'metadata'), the file could change for each commit (e.g.
'metadata.nnn') where nnn is the revision number, so each commit
deletes the old metadata file and writes the new metadata file.
Monticello could know to use whichever single 'metadata.*' file
exists. Would that avoid the problem of metadata merge conflict?
I've thought of that, and it seems hard to get right (which file goes
first? how do you recognize a merge?). You have to remember that
packages have hundreds, even thousands of versions so this would mean
that number of files.
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
Thierry
