But this add a serious indirection layer. In Java, since there is no image, doing a pull update your code. In Pharo, it would simply update the git repo, without updating the code in your image. What’s happens if I modify the code in my image and do a git pull? I will have conflict between my image and the git repo. That was the very first scenario I did when I tried Git. No no no, that is completely broken.
Alexandre > On Sep 11, 2015, at 10:38 AM, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > > > > Le 11 septembre 2015 15:33, Alexandre Bergel <alexandre.ber...@me.com> a > écrit : > [ 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. > > No, this is not an issue. By design, the state of your code in your image is > not kept in sync with a repository; you can be n versions behind the latest > in the repository, if you like. This is the case with Smalltalkhub. A pull in > git only amounts to a more extensive refresh in a Smalltalkhub repository. > > Thierry > > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
