2015-09-11 15:47 GMT+02:00 Alexandre Bergel <alexandre.ber...@me.com>:
> 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. > Come on, you know that your java code is a dead thing, without any live capability, and going this way would be a huge step backward in Smalltalk. Speaking of Roassal, I'm sure that if I start developping on it, after a week, I'm out of sync for at least ten version of it and unable to merge back my fixes in it, and that would be with Smalltalkhub. Me on a git workflow with Roassal? Piece of cake. Remember that you work differently on git and over smalltalkhub. In Smalltalkhub, you avoid branches and have only one master; in git you'll have plenty of branches and avoid doing work directly on master, because of the out of sync effects (and frequent merges). Thierry > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
