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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
