[ answer in the mailing list since it may interest other ] Another problem would be the synchronization between the image and the source code stored on disk. For example, I should never do a git pull within a xterm command, because the image will not be sync.
Alexandre > On Sep 11, 2015, at 4:56 AM, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > Salut Alexandre, > > je creuse encore un peu l'idée de l'autre format et... > > - Le format "chunk/fileout" de Pharo ne comporte pas les infos nécessaires à > Monticello; le même fichier "version" si embêtant sous git est dans le mcz > (et s'il était mis dans le .st, on aurait les mêmes conflits sous git merge, > mais sans doute plus compliqué). > - Si on passe sur un format n'ayant pas cette info de version, il faut > absolument passer par git pour la récupérer. Or git et windows ça ne marche > pas encore correctement. Ça limiterait le nouveau format à Mac et Linux :( > > Bienvenue dans ce bazar très désagréable à contempler. > > Thierry > . > > 2015-09-11 1:47 GMT+02:00 Alexandre Bergel <alexandre.ber...@me.com>: > > moi je me demanderais juste une chose, du point de vue que j'ai quand je > > discute transfert de technologie : est-ce que ça sert à quelque chose > > d'investir là-dedans ? > > Ben j’aimerai pouvoir utiliser Git au lieu de SmalltalkHub. > > > En gros, FileTree marche très bien (avec des ratés sous windows en cours de > > résolution), GitFileTree marche très bien (avec des ratés sous windows), le > > merge driver marche très bien. Pourquoi veux-tu changer de format ? > > Pour ne pas à avoir à modifier le .gitconfig et le .gitattributes. > > J’ai un nouveau cours où j’enseigne Pharo. Mais je ne me vois pas vraiment > leur dire de suivre la procédure sur > https://github.com/ThierryGoubier/GitFileTree-MergeDriver . Cela marche mais > c’est particulièrement complexe. > > Alexandre > > > > > > L'investissement qui fait sens pour moi est: > > - Corriger ProcessWrapper sous Windows > > ou > > - Travailler sur l'intégration de libcgit > > et > > - Travailler sur un outil de résolution de conflit git sous Pharo (pour > > éviter d'avoir à utiliser meld et compagnie). > > > > Tu sais, je peux te vendre* ce que serait la chaîne git parfaite pour > > Pharo, et je ne te parlerais pas du format ou d'en changer. > > > > * te faire le pitch investisseur / VC > > > > ** C'est vraiment la merde de rajouter des types supplémentaires de > > repository dans Pharo, donc c'est aussi pour ça que je ne l'encourage pas > > trop. > > > > *** Mais en même temps, c'est un sujet très important, donc c'est bien > > qu'on en discute. > > > > Thierry > > > > Le 10/09/2015 23:11, Alexandre Bergel a écrit : > >> [ This is a private message ] > >> > >> This is a topic very important for me. Would you like to guide an > >> engineer if I get one? Milton is a very competent engineer. I really > >> would like this topic move on. > >> > >> Cheers, > >> Alexandre > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Sep 10, 2015, at 4:04 PM, Thierry Goubier > >>> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>> wrote: > >>> > >>> Le 10/09/2015 20:29, Alexandre Bergel a écrit : > >>>>>>> But, all well considered, relying only on the underlying vcs for > >>>>>>> versions, but writing chunk files, could it work? With the > >>>>>>> gitfiletree framework, all version / meta information is external > >>>>>>> to the source files, so Metacello could use that and have > >>>>>>> everything it needs. Would someone be interested by that? > >>>> > >>>> Are you suggesting to have a different format, which could be .mcs that > >>>> is like .mcz but without all the metadata? > >>> > >>> That would be that. The mcs would be the chunk format that Pharo and > >>> all Smalltalks have (i.e. fileouts). > >>> > >>>> This means that we will need > >>>> another UI since Monticello will not work. > >>> > >>> No, it would simply be another type of repository for Monticello. I > >>> have already done the work for GitFileTree (recreate a MC-like API > >>> even if the metadata comes from git instead of the mcz), and you would > >>> reuse that. > >>> > >>> It would be totally transparent to you. Metacello, Gofer, > >>> Configurations would work. > >>> > >>>> Can you estimate the amount of work to do? > >>> > >>> I'd start from GitFileTree, isolate the git commands and the MC API > >>> and copy them to the new repository type, add a chunk reader over a > >>> zip archive, and add the chunk writer. I'd reuse the GitFileTree > >>> repository inspector because it is already designed for that. > >>> > >>> For someone who knows a bit the internals of a MC repository, it > >>> wouldn't take long. > >>> > >>> Shouldn't forget to have a good chunk of tests cases and sample > >>> repositories: filetree would be my reference there. > >>> > >>> Thierry > >>> > >>>> Alexandre > >>> > >>> > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
