2014-05-27 22:19 GMT+02:00 Esteban Lorenzano <[email protected]>: > > On 27 May 2014, at 17:09, [email protected] wrote: > > On Tue, May 27, 2014 at 9:21 PM, Nicolas Cellier < > [email protected]> wrote: > >> >> 2014-05-27 20:41 GMT+02:00 Johan Brichau <[email protected]>: >> >>> Have you tried this? >>> >>> https://github.com/ThierryGoubier/GitFileTree-MergeDriver >>> >>> Not sure about the ^M problem though... >>> >>> Johan >>> >>> >> I second this, with GitFileTree it solves most problems of false >> conflicts caused by MC metadata. >> For true conflicts, I did not inquire. >> > > Ok, will have a look. > > At first sight, it looks scary and less friendly than a plain old MCZ > merge. > > But... git is the standard and it is painful to have to maintain things in > two places… > > > filetree format is buggy when merging. Reason is is keeping monticello > metadata and that does not plays very good with git (bah, it does not play > good at all). >
As long as the metadata (package ancestry, commit comments, ...) is kept into the image, it plays remarkably well. Good enough to help maintaining Squeak and Pharo projects for ten years or so, as well as a few others (croquet/cobalt, etoys, the VM, etc...) Everything into the image is such a simple model that Pharo now want the whole source in the image rather than in a file, no ;) Yes, these metadata are growing, but I'm pretty sure that this simple model can scale for a few more years. I agree that MC has a problem at server side with files, files make an awfull database! But alternate solutions exist (like magma). MC has another problem with IDs (GUID were not appended to file names, I really don't know why). For packaging an artefact made of several Smalltalk packages, the simplicity of MonticelloConfiguration (MCM) as used in Squeak rocks (simple tools for simple tasks). For me, git make sense for other reasons - mixed language development (like the VM) - visibility, social/collaborative tools like github (pull request, code reviews etc...) - very efficient branching (but it's a false assumption that MC can't do branching, it's more that MCM can't) Git is very powerfull, efficient, light, scales very well, it's from far the best option available for SCM... But in term of simplicity, please think twice for the next generation of in image tools, MC rocks, I wish you invent something as simple and efficient. Nicolas We are working (Max is doing some work there) in a better integration with > git, where we can drop all those metadata files and rely on git information > (it is there, we just need to use it). But as always, things needs time and > time is scarce :(. > > My recommendation in the mean time is to try gitfiletree. There is a good > chance that it fixes your problems. > > Esteban > > > Phil > > >> >> >>> On 27 May 2014, at 20:38, [email protected] wrote: >>> >>> > Hello, >>> > >>> > I am working with Sebastian on some code and we tried out filetree:// >>> > >>> > We have our packages saved there on disk and then we commit/push them >>> on the git server. >>> > >>> > Now, as we develop and then need to merge, I find it hard to do those >>> merges on the .st files. >>> > >>> > As ^M is used as separator, the merge tools seem to have a difficult >>> time and show us 2 huge lines. >>> > >>> > What is the current best practice for merging packages that way? >>> > >>> > TIA >>> > Phil >>> >>> >>> >> > >
