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