Le 28/09/2015 04:27, Ben Coman a écrit :
I have a vague recollection that the problem was a particular file
where data changed each commit and having the idea that this might be
solved by: each commit writing metadata to a different file e.g.
NNNN.metadata, and Monticello knows to pick up the highest numbered
metadata.
Hum, I thought that as well, but in fact write the merge driver turned
out as far better and simpler. Moreover, all type of data oriented files
(ston, json, version) do not merge properly in git. So even Esteban
saying he will use STON does not seems to solve the merge issue, unless
he is planning something else. I do take in account we will have more
metadata in the future, thanks to EPICEA, so we need a way to handle it.
Merging is easy, you just need to hook into it.
I believed also that we could do the merge ourselves and force git to
commit the result, but discovered this was a bad idea. Imagine having to
fire Pharo to merge a 250k OCaml project with 2k of st code in it :(
Git is very flexible which implies complexity for newcomers to it.
What is required on top of git is a "well defined" workflow. I see
sometimes on this mail-list that people design their tools for
flexibility since they don't want to *impose* a workflow on people,
which is a commendable philosophy, but slows adoption by newcomers.
It may be useful to define "this is *the* way its done here" , with
the standard proviso that there may be missteps that need to be tuned.
Unless you have some experience of Monticello, Metacello, the Pharo
workflow, some of the workflow outside Pharo, and git, then defining
this workflow is shooting in the dark. So, first attempts are either:
- be flexible, so that you fit into a pre-existing workflow, and explore
options,
- be dictatorial in your shot in the dark, and pray you got it right.
Now, we've solved all the hard points (apart from the Windows support),
so we can imagine a future.
Thierry
