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