2015-09-11 15:47 GMT+02:00 Alexandre Bergel <alexandre.bergel@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.goubier@gmail.com> wrote:
>
>
>
> Le 11 septembre 2015 15:33, Alexandre Bergel <alexandre.bergel@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.goubier@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.bergel@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.goubier@gmail.com <mailto:thierry.goubier@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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.