- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Metacello-github + filetree-git async

by GOUBIER Thierry

________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Damien Pollet [damien.pollet(a)gmail.com] EnvoyÃ© : jeudi 10 juillet 2014 18:59 Ã : Pharo Development List Objet : Re: [Pharo-dev] Metacello-github + filetree-git async as far as I am concerned (I'm certainly not up-to-date on recent enhancements)â¦ - filetree is a pain because of the double-commit workflow (MC with dummy message to serialize, then git) - gitfiletree is a pain because it insists on using a file browser that shows all dotfiles and starts in the stupidest of places Starting in one of the default places linked to the image. Yes, this is annoying... I'll look into it. - github is just a snapshot (no updates, no contributions) - there is a mysterious new "remote git repo" that either uses gitfiletree or the new libgit2 bindings, but I'm not sure what all the parameters are exactly (name of what? subdirectory of where?) GitFileTree for the time being: http://forum.world.st/ANN-GitFileTree-with-no-git-command-line-at-all-td474… This promises to coalesce into a nice workflow, though. Can't wait :D It works as of now :) I'm trying to document some of it in the GitAndPharo chapter of Pharo for the enterprise. Thierry On 10 July 2014 18:47, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I am interested to know too. > > ATM I do a clone and use filetree:// > > Phil > > > > On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet <damien.pollet(a)gmail.com> > wrote: >> >> Sorry to hijack this discussionâ¦ is it by design that the github: >> scheme takes a snapshot instead of a git clone? >> >> github: is convenient for the metacello syntax, but since it just >> takes a snapshot of a commit, there is no immediate way of pushing >> changes back. Converting what's on disk to a proper git clone is also >> not practical since the path of the snapshot under github-cache is >> specific to the particular commit. >> >> On 6 March 2014 13:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> > Ok, I see now. >> > >> > I don't think this can be avoided; it's inherent in the way both github: >> > and >> > gitfiletree: understand repositories. The explanation will go a bit into >> > git >> > and gitfiletree design and FileTree; in the mean time, you may either >> > change >> > a bit the config to clean that (force a load of the last version from >> > gitfiletree, since they are effectively the same) or don't bother, >> > gitfiletree: when saving a new package version will clear that (sort >> > of). >> > >> > The explanation is a bit long. >> > >> > version metadata for FileTree (the format used to write packages for git >> > and >> > others version control systems) is stored in a file under >> > PackageName.package/monticello.meta/versions. >> > >> > This file is often a problem, at least under git: it's a magnet for git >> > merge conflicts. It is also slow to parse[1], especially if you want to >> > know >> > all the versions of the package stored by the git repository (as >> > gitfiletree >> > does), and sometimes is corrupted (git conflicts). >> > >> > So, in the design of gitfiletree:, I decided that I would not read this >> > file, but, instead, recreate its contents from the git log history[2]. >> > This >> > is what you see when you open a gitfiletree: repository. And >> > particularly, >> > versions UUIDs are generated from the git commit ID[3]. >> > >> > Now, when saving a package in a gitfiletree: repository, the versions >> > file >> > will be written, with an UUID generated for it... except that, on >> > rereading, >> > gitfiletree will generate another UUID from the git commitID (which is >> > known, of course, after committing the versions file :() >> > >> > For example, in gitfiletree:, >> > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 >> > Whereas the file Renraku.package/monticello.meta/versions has >> > Renraku-YuriyTymchuk.4 with id >> > '60141668-a324-4c9d-8938-db82ed2e57de' >> > >> > Older versions are regenerated from the git data, and this is why, in >> > that >> > file, you see >> > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) >> > >> > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 >> > times the versions file for a moderatly complex project, including the >> > fact >> > that it's easy to find a corrupted versions file in a git repo. >> > Generating >> > ended up a lot cleaner, as well as garanteeing than the history would be >> > browsable. >> > >> > [2] And filtering the git history to keep only the commits significant >> > for >> > the package, and nothing else. >> > >> > [3] Constant mapping: a given git commitID will allways generate the >> > same >> > UUID. >> > >> > Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : >> >> >> >> >> >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >> >>> >> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >> >>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>> >> >>>> >> >>>> >> >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : >> >>>>> >> >>>>> >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >> >>>>>>> >> >>>>>>> >> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : >> >>>>>>>>> >> >>>>>>>>> Hi guys. >> >>>>>>>>> >> >>>>>>>>> My workflow is like this: >> >>>>>>>>> >> >>>>>>>>> I load a configuration on CI with github:// magic in metacello >> >>>>>>>>> conf. >> >>>>>>>>> Then on local machine I add a local gitfiletree repo to the >> >>>>>>>>> project packages. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> The thing is that the last version if loaded, but gitfiletree >> >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with >> >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and >> >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show >> >>>>>>>>> changes that were mede in last version. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, >> >>>>>>>> .3, and .4 , like that? >> >>>>>>> >> >>>>>>> >> >>>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". >> >>>>>> >> >>>>>> >> >>>>>> Are changes shown when you click on the .5 version in gitfiletree? >> >>>>>> on the .4 version in gitfiletree as well? >> >>>>> >> >>>>> >> >>>>> Version 5 does not have changes with working copy. While version 4 >> >>>>> has. So from my point of view it seams like version 5 is loaded but >> >>>>> gitfiletree thinks that only version 4 is loaded. >> >>>> >> >>>> >> >>>> Understood. Is it a problem if I have a look at the image or at the >> >>>> git repository? >> >>> >> >>> >> >>> When I look in the monticello browser in the image. >> >> >> >> >> >> And with applies to the both packages I have in that repo >> >> >> >>> >> >>>> >> >>>> Thierry >> >>>> -- >> >>>> Thierry Goubier >> >>>> CEA list >> >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> >>>> 91191 Gif sur Yvette Cedex >> >>>> France >> >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> >> > >> > -- >> > Thierry Goubier >> > CEA list >> > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> > 91191 Gif sur Yvette Cedex >> > France >> > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Dale Henrichs

Damien On Thu, Jul 10, 2014 at 9:59 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > as far as I am concerned (I'm certainly not up-to-date on recent > enhancements)â¦ > > - filetree is a pain because of the double-commit workflow (MC with > dummy message to serialize, then git) > Thierry's MergeDriver has made the monticello meta data conflicts a non-issue ... since using his merge driver they've gone away as far as I am concerned ... I don't think the meta data can go away until a firm break with mcz files has been made and this cannot really happen until the image has full tool support for working with pure git repos and even then there will be a transition period ... - gitfiletree is a pain because it insists on using a file browser > that shows all dotfiles and starts in the stupidest of places > - github is just a snapshot (no updates, no contributions) > - there is a mysterious new "remote git repo" that either uses > gitfiletree or the new libgit2 bindings, but I'm not sure what all the > parameters are exactly (name of what? subdirectory of where?) > > This promises to coalesce into a nice workflow, though. Can't wait :D I cannot comment on the other things, but for GemStone I am building git support into tODE and have created a `project list` that I think supports git work flow in the "right way" (I am doing a pre-alpha release shortly, I will find out:) ... but the point of this is that I think you almost have to build a new tool suite for managing projects and git repos together and that just takes time ... the old package-base tools are not quite at right level, since with git it is possible to look at method history, class history, package history and project history and when you do a commit, you should be committing all of the packages in the project at the same time (or at least have the option of doing so)... Dale

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Dale Henrichs

Damien, Yes it was by design to just snapshot ... At the time, git was not necessarily familiar to most smalltalkers and I didn't want to require that git be installed or that a user understand how to use git, just to download and _use_ the code of a project that was hosted on github. A clone can be much larger than a simple snapshot and with the snapshot, I was able to create a git-cache directory that could be blown away at any time (much like the package-cache). Finally, if you wanted to save your changes you had to do these things outside the image. So _at the time_ the snapshot seemed to be a good compromise ... In my work flow, I tend to share most of my git repositories and I in this case I don't want N different git repositories for the same project on my disk... For that reason, the Metacello Preview has a feature for 'locking' a project. When you lock a project, you are telling Metacello that no matter what version or repository a project references always use the (in my case) local git repository... I pre-emptively lock the repositories that I am managing as local repositories and then I don't have to mess with reloading the version from my local repo ... If you have referenced a github repo and you do want to make a contribution to, then you should probably fork the project up on github and then clone a copy of your fork to the local disk and then "hook" the local clone into your image ... I have written some commands for tODE that automate this task ... and I'm willing to share:) Dale On Thu, Jul 10, 2014 at 9:28 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Sorry to hijack this discussionâ¦ is it by design that the github: > scheme takes a snapshot instead of a git clone? > > github: is convenient for the metacello syntax, but since it just > takes a snapshot of a commit, there is no immediate way of pushing > changes back. Converting what's on disk to a proper git clone is also > not practical since the path of the snapshot under github-cache is > specific to the particular commit. > > On 6 March 2014 13:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > Ok, I see now. > > > > I don't think this can be avoided; it's inherent in the way both github: > and > > gitfiletree: understand repositories. The explanation will go a bit into > git > > and gitfiletree design and FileTree; in the mean time, you may either > change > > a bit the config to clean that (force a load of the last version from > > gitfiletree, since they are effectively the same) or don't bother, > > gitfiletree: when saving a new package version will clear that (sort of). > > > > The explanation is a bit long. > > > > version metadata for FileTree (the format used to write packages for git > and > > others version control systems) is stored in a file under > > PackageName.package/monticello.meta/versions. > > > > This file is often a problem, at least under git: it's a magnet for git > > merge conflicts. It is also slow to parse[1], especially if you want to > know > > all the versions of the package stored by the git repository (as > gitfiletree > > does), and sometimes is corrupted (git conflicts). > > > > So, in the design of gitfiletree:, I decided that I would not read this > > file, but, instead, recreate its contents from the git log history[2]. > This > > is what you see when you open a gitfiletree: repository. And > particularly, > > versions UUIDs are generated from the git commit ID[3]. > > > > Now, when saving a package in a gitfiletree: repository, the versions > file > > will be written, with an UUID generated for it... except that, on > rereading, > > gitfiletree will generate another UUID from the git commitID (which is > > known, of course, after committing the versions file :() > > > > For example, in gitfiletree:, > > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 > > Whereas the file Renraku.package/monticello.meta/versions has > > Renraku-YuriyTymchuk.4 with id > > '60141668-a324-4c9d-8938-db82ed2e57de' > > > > Older versions are regenerated from the git data, and this is why, in > that > > file, you see > > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) > > > > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 > > times the versions file for a moderatly complex project, including the > fact > > that it's easy to find a corrupted versions file in a git repo. > Generating > > ended up a lot cleaner, as well as garanteeing than the history would be > > browsable. > > > > [2] And filtering the git history to keep only the commits significant > for > > the package, and nothing else. > > > > [3] Constant mapping: a given git commitID will allways generate the same > > UUID. > > > > Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : > >> > >> > >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > >> <mailto:yuriy.tymchuk@me.com>> wrote: > >> > >>> > >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr > >>> <mailto:thierry.goubier@cea.fr>> wrote: > >>> > >>>> > >>>> > >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : > >>>>> > >>>>> > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : > >>>>>>> > >>>>>>> > >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : > >>>>>>>>> > >>>>>>>>> Hi guys. > >>>>>>>>> > >>>>>>>>> My workflow is like this: > >>>>>>>>> > >>>>>>>>> I load a configuration on CI with github:// magic in metacello > >>>>>>>>> conf. > >>>>>>>>> Then on local machine I add a local gitfiletree repo to the > >>>>>>>>> project packages. > >>>>>>>> > >>>>>>>> > >>>>>>>>> The thing is that the last version if loaded, but gitfiletree > >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with > >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and > >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show > >>>>>>>>> changes that were mede in last version. > >>>>>>>> > >>>>>>>> > >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, > >>>>>>>> .3, and .4 , like that? > >>>>>>> > >>>>>>> > >>>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". > >>>>>> > >>>>>> > >>>>>> Are changes shown when you click on the .5 version in gitfiletree? > >>>>>> on the .4 version in gitfiletree as well? > >>>>> > >>>>> > >>>>> Version 5 does not have changes with working copy. While version 4 > >>>>> has. So from my point of view it seams like version 5 is loaded but > >>>>> gitfiletree thinks that only version 4 is loaded. > >>>> > >>>> > >>>> Understood. Is it a problem if I have a look at the image or at the > >>>> git repository? > >>> > >>> > >>> When I look in the monticello browser in the image. > >> > >> > >> And with applies to the both packages I have in that repo > >> > >>> > >>>> > >>>> Thierry > >>>> -- > >>>> Thierry Goubier > >>>> CEA list > >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > >>>> 91191 Gif sur Yvette Cedex > >>>> France > >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >> > >> > > > > -- > > Thierry Goubier > > CEA list > > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > 91191 Gif sur Yvette Cedex > > France > > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Damien Pollet

as far as I am concerned (I'm certainly not up-to-date on recent enhancements)â¦ - filetree is a pain because of the double-commit workflow (MC with dummy message to serialize, then git) - gitfiletree is a pain because it insists on using a file browser that shows all dotfiles and starts in the stupidest of places - github is just a snapshot (no updates, no contributions) - there is a mysterious new "remote git repo" that either uses gitfiletree or the new libgit2 bindings, but I'm not sure what all the parameters are exactly (name of what? subdirectory of where?) This promises to coalesce into a nice workflow, though. Can't wait :D On 10 July 2014 18:47, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I am interested to know too. > > ATM I do a clone and use filetree:// > > Phil > > > > On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet <damien.pollet(a)gmail.com> > wrote: >> >> Sorry to hijack this discussionâ¦ is it by design that the github: >> scheme takes a snapshot instead of a git clone? >> >> github: is convenient for the metacello syntax, but since it just >> takes a snapshot of a commit, there is no immediate way of pushing >> changes back. Converting what's on disk to a proper git clone is also >> not practical since the path of the snapshot under github-cache is >> specific to the particular commit. >> >> On 6 March 2014 13:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> > Ok, I see now. >> > >> > I don't think this can be avoided; it's inherent in the way both github: >> > and >> > gitfiletree: understand repositories. The explanation will go a bit into >> > git >> > and gitfiletree design and FileTree; in the mean time, you may either >> > change >> > a bit the config to clean that (force a load of the last version from >> > gitfiletree, since they are effectively the same) or don't bother, >> > gitfiletree: when saving a new package version will clear that (sort >> > of). >> > >> > The explanation is a bit long. >> > >> > version metadata for FileTree (the format used to write packages for git >> > and >> > others version control systems) is stored in a file under >> > PackageName.package/monticello.meta/versions. >> > >> > This file is often a problem, at least under git: it's a magnet for git >> > merge conflicts. It is also slow to parse[1], especially if you want to >> > know >> > all the versions of the package stored by the git repository (as >> > gitfiletree >> > does), and sometimes is corrupted (git conflicts). >> > >> > So, in the design of gitfiletree:, I decided that I would not read this >> > file, but, instead, recreate its contents from the git log history[2]. >> > This >> > is what you see when you open a gitfiletree: repository. And >> > particularly, >> > versions UUIDs are generated from the git commit ID[3]. >> > >> > Now, when saving a package in a gitfiletree: repository, the versions >> > file >> > will be written, with an UUID generated for it... except that, on >> > rereading, >> > gitfiletree will generate another UUID from the git commitID (which is >> > known, of course, after committing the versions file :() >> > >> > For example, in gitfiletree:, >> > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 >> > Whereas the file Renraku.package/monticello.meta/versions has >> > Renraku-YuriyTymchuk.4 with id >> > '60141668-a324-4c9d-8938-db82ed2e57de' >> > >> > Older versions are regenerated from the git data, and this is why, in >> > that >> > file, you see >> > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) >> > >> > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 >> > times the versions file for a moderatly complex project, including the >> > fact >> > that it's easy to find a corrupted versions file in a git repo. >> > Generating >> > ended up a lot cleaner, as well as garanteeing than the history would be >> > browsable. >> > >> > [2] And filtering the git history to keep only the commits significant >> > for >> > the package, and nothing else. >> > >> > [3] Constant mapping: a given git commitID will allways generate the >> > same >> > UUID. >> > >> > Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : >> >> >> >> >> >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >> >>> >> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >> >>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>> >> >>>> >> >>>> >> >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : >> >>>>> >> >>>>> >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >> >>>>>>> >> >>>>>>> >> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >> >>>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >> >>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : >> >>>>>>>>> >> >>>>>>>>> Hi guys. >> >>>>>>>>> >> >>>>>>>>> My workflow is like this: >> >>>>>>>>> >> >>>>>>>>> I load a configuration on CI with github:// magic in metacello >> >>>>>>>>> conf. >> >>>>>>>>> Then on local machine I add a local gitfiletree repo to the >> >>>>>>>>> project packages. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> The thing is that the last version if loaded, but gitfiletree >> >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with >> >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and >> >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show >> >>>>>>>>> changes that were mede in last version. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, >> >>>>>>>> .3, and .4 , like that? >> >>>>>>> >> >>>>>>> >> >>>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". >> >>>>>> >> >>>>>> >> >>>>>> Are changes shown when you click on the .5 version in gitfiletree? >> >>>>>> on the .4 version in gitfiletree as well? >> >>>>> >> >>>>> >> >>>>> Version 5 does not have changes with working copy. While version 4 >> >>>>> has. So from my point of view it seams like version 5 is loaded but >> >>>>> gitfiletree thinks that only version 4 is loaded. >> >>>> >> >>>> >> >>>> Understood. Is it a problem if I have a look at the image or at the >> >>>> git repository? >> >>> >> >>> >> >>> When I look in the monticello browser in the image. >> >> >> >> >> >> And with applies to the both packages I have in that repo >> >> >> >>> >> >>>> >> >>>> Thierry >> >>>> -- >> >>>> Thierry Goubier >> >>>> CEA list >> >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> >>>> 91191 Gif sur Yvette Cedex >> >>>> France >> >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> >> >> >> > >> > -- >> > Thierry Goubier >> > CEA list >> > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> > 91191 Gif sur Yvette Cedex >> > France >> > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by phil＠highoctane.be

I am interested to know too. ATM I do a clone and use filetree:// Phil On Thu, Jul 10, 2014 at 6:28 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Sorry to hijack this discussionâ¦ is it by design that the github: > scheme takes a snapshot instead of a git clone? > > github: is convenient for the metacello syntax, but since it just > takes a snapshot of a commit, there is no immediate way of pushing > changes back. Converting what's on disk to a proper git clone is also > not practical since the path of the snapshot under github-cache is > specific to the particular commit. > > On 6 March 2014 13:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > Ok, I see now. > > > > I don't think this can be avoided; it's inherent in the way both github: > and > > gitfiletree: understand repositories. The explanation will go a bit into > git > > and gitfiletree design and FileTree; in the mean time, you may either > change > > a bit the config to clean that (force a load of the last version from > > gitfiletree, since they are effectively the same) or don't bother, > > gitfiletree: when saving a new package version will clear that (sort of). > > > > The explanation is a bit long. > > > > version metadata for FileTree (the format used to write packages for git > and > > others version control systems) is stored in a file under > > PackageName.package/monticello.meta/versions. > > > > This file is often a problem, at least under git: it's a magnet for git > > merge conflicts. It is also slow to parse[1], especially if you want to > know > > all the versions of the package stored by the git repository (as > gitfiletree > > does), and sometimes is corrupted (git conflicts). > > > > So, in the design of gitfiletree:, I decided that I would not read this > > file, but, instead, recreate its contents from the git log history[2]. > This > > is what you see when you open a gitfiletree: repository. And > particularly, > > versions UUIDs are generated from the git commit ID[3]. > > > > Now, when saving a package in a gitfiletree: repository, the versions > file > > will be written, with an UUID generated for it... except that, on > rereading, > > gitfiletree will generate another UUID from the git commitID (which is > > known, of course, after committing the versions file :() > > > > For example, in gitfiletree:, > > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 > > Whereas the file Renraku.package/monticello.meta/versions has > > Renraku-YuriyTymchuk.4 with id > > '60141668-a324-4c9d-8938-db82ed2e57de' > > > > Older versions are regenerated from the git data, and this is why, in > that > > file, you see > > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) > > > > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 > > times the versions file for a moderatly complex project, including the > fact > > that it's easy to find a corrupted versions file in a git repo. > Generating > > ended up a lot cleaner, as well as garanteeing than the history would be > > browsable. > > > > [2] And filtering the git history to keep only the commits significant > for > > the package, and nothing else. > > > > [3] Constant mapping: a given git commitID will allways generate the same > > UUID. > > > > Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : > >> > >> > >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com > >> <mailto:yuriy.tymchuk@me.com>> wrote: > >> > >>> > >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr > >>> <mailto:thierry.goubier@cea.fr>> wrote: > >>> > >>>> > >>>> > >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : > >>>>> > >>>>> > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : > >>>>>>> > >>>>>>> > >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr > >>>>>>> <mailto:thierry.goubier@cea.fr>> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : > >>>>>>>>> > >>>>>>>>> Hi guys. > >>>>>>>>> > >>>>>>>>> My workflow is like this: > >>>>>>>>> > >>>>>>>>> I load a configuration on CI with github:// magic in metacello > >>>>>>>>> conf. > >>>>>>>>> Then on local machine I add a local gitfiletree repo to the > >>>>>>>>> project packages. > >>>>>>>> > >>>>>>>> > >>>>>>>>> The thing is that the last version if loaded, but gitfiletree > >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with > >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and > >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show > >>>>>>>>> changes that were mede in last version. > >>>>>>>> > >>>>>>>> > >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, > >>>>>>>> .3, and .4 , like that? > >>>>>>> > >>>>>>> > >>>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". > >>>>>> > >>>>>> > >>>>>> Are changes shown when you click on the .5 version in gitfiletree? > >>>>>> on the .4 version in gitfiletree as well? > >>>>> > >>>>> > >>>>> Version 5 does not have changes with working copy. While version 4 > >>>>> has. So from my point of view it seams like version 5 is loaded but > >>>>> gitfiletree thinks that only version 4 is loaded. > >>>> > >>>> > >>>> Understood. Is it a problem if I have a look at the image or at the > >>>> git repository? > >>> > >>> > >>> When I look in the monticello browser in the image. > >> > >> > >> And with applies to the both packages I have in that repo > >> > >>> > >>>> > >>>> Thierry > >>>> -- > >>>> Thierry Goubier > >>>> CEA list > >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > >>>> 91191 Gif sur Yvette Cedex > >>>> France > >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >> > >> > > > > -- > > Thierry Goubier > > CEA list > > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > 91191 Gif sur Yvette Cedex > > France > > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

July 10, 2014

Re: [Pharo-dev] Metacello-github + filetree-git async

by Damien Pollet

Sorry to hijack this discussionâ¦ is it by design that the github: scheme takes a snapshot instead of a git clone? github: is convenient for the metacello syntax, but since it just takes a snapshot of a commit, there is no immediate way of pushing changes back. Converting what's on disk to a proper git clone is also not practical since the path of the snapshot under github-cache is specific to the particular commit. On 6 March 2014 13:42, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Ok, I see now. > > I don't think this can be avoided; it's inherent in the way both github: and > gitfiletree: understand repositories. The explanation will go a bit into git > and gitfiletree design and FileTree; in the mean time, you may either change > a bit the config to clean that (force a load of the last version from > gitfiletree, since they are effectively the same) or don't bother, > gitfiletree: when saving a new package version will clear that (sort of). > > The explanation is a bit long. > > version metadata for FileTree (the format used to write packages for git and > others version control systems) is stored in a file under > PackageName.package/monticello.meta/versions. > > This file is often a problem, at least under git: it's a magnet for git > merge conflicts. It is also slow to parse[1], especially if you want to know > all the versions of the package stored by the git repository (as gitfiletree > does), and sometimes is corrupted (git conflicts). > > So, in the design of gitfiletree:, I decided that I would not read this > file, but, instead, recreate its contents from the git log history[2]. This > is what you see when you open a gitfiletree: repository. And particularly, > versions UUIDs are generated from the git commit ID[3]. > > Now, when saving a package in a gitfiletree: repository, the versions file > will be written, with an UUID generated for it... except that, on rereading, > gitfiletree will generate another UUID from the git commitID (which is > known, of course, after committing the versions file :() > > For example, in gitfiletree:, > Renraku-Uko.4 has UUID: 93fec7ab-e167-5da5-9b2e-5d717d2c7545 > Whereas the file Renraku.package/monticello.meta/versions has > Renraku-YuriyTymchuk.4 with id > '60141668-a324-4c9d-8938-db82ed2e57de' > > Older versions are regenerated from the git data, and this is why, in that > file, you see > Renraku-Uko.3 (and not Renraku-YuriyTymchuk.3) > > [1] Yes, and I tried long and hard to accelerate reading and parsing 200 > times the versions file for a moderatly complex project, including the fact > that it's easy to find a corrupted versions file in a git repo. Generating > ended up a lot cleaner, as well as garanteeing than the history would be > browsable. > > [2] And filtering the git history to keep only the commits significant for > the package, and nothing else. > > [3] Constant mapping: a given git commitID will allways generate the same > UUID. > > Le 06/03/2014 11:41, Yuriy Tymchuk a Ã©crit : >> >> >> On 06 Mar 2014, at 11:35, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> <mailto:yuriy.tymchuk@me.com>> wrote: >> >>> >>> On 06 Mar 2014, at 11:17, Goubier Thierry <thierry.goubier(a)cea.fr >>> <mailto:thierry.goubier@cea.fr>> wrote: >>> >>>> >>>> >>>> Le 06/03/2014 11:09, Yuriy Tymchuk a Ã©crit : >>>>> >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 06 Mar 2014, at 10:28, Goubier Thierry <thierry.goubier(a)cea.fr >>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Le 06/03/2014 10:08, Yuriy Tymchuk a Ã©crit : >>>>>>> >>>>>>> >>>>>>> On 06 Mar 2014, at 09:48, Goubier Thierry <thierry.goubier(a)cea.fr >>>>>>> <mailto:thierry.goubier@cea.fr>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 06/03/2014 09:32, Yuriy Tymchuk a Ã©crit : >>>>>>>>> >>>>>>>>> Hi guys. >>>>>>>>> >>>>>>>>> My workflow is like this: >>>>>>>>> >>>>>>>>> I load a configuration on CI with github:// magic in metacello >>>>>>>>> conf. >>>>>>>>> Then on local machine I add a local gitfiletree repo to the >>>>>>>>> project packages. >>>>>>>> >>>>>>>> >>>>>>>>> The thing is that the last version if loaded, but gitfiletree >>>>>>>>> repo is showing that second last is loaded. And yes, diffs with >>>>>>>>> last one (not loaded by gitfiletree opinion) show no changes and >>>>>>>>> diffs with second last (current one by gitfiletree opinion) show >>>>>>>>> changes that were mede in last version. >>>>>>>> >>>>>>>> >>>>>>>> Say version .5 on CI, and gitfiletree is showing you only .1, .2, >>>>>>>> .3, and .4 , like that? >>>>>>> >>>>>>> >>>>>>> I also see the .5 version, but itâs bold i.e. ânot loaded". >>>>>> >>>>>> >>>>>> Are changes shown when you click on the .5 version in gitfiletree? >>>>>> on the .4 version in gitfiletree as well? >>>>> >>>>> >>>>> Version 5 does not have changes with working copy. While version 4 >>>>> has. So from my point of view it seams like version 5 is loaded but >>>>> gitfiletree thinks that only version 4 is loaded. >>>> >>>> >>>> Understood. Is it a problem if I have a look at the image or at the >>>> git repository? >>> >>> >>> When I look in the monticello browser in the image. >> >> >> And with applies to the both packages I have in that repo >> >>> >>>> >>>> Thierry >>>> -- >>>> Thierry Goubier >>>> CEA list >>>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>>> 91191 Gif sur Yvette Cedex >>>> France >>>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2014

Thanks for NewVersionBrowser

by Goubier Thierry

Hi All, while porting AltBrowser to Pharo4, I had to change my code from the old VersionsBrowser to the NewVersionBrowser based on Spec (for the Git-based method version browser). And I must say: thanks ! The NewVersionBrowser is so easy to extend to use MCMethodDefinitions instead of ChangeRecords, it's like a dream... Being able to wipe out so much ugly unnecessary code :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

July 10, 2014

Handling side-scrolls

by Yuriy Tymchuk

Dear Pharo developers, can we deal somehow with this issue: https://pharo.fogbugz.com/f/cases/5296/Fast-Scroll-Down-produces-weird-even… ? Or at least please tell me if someone needs this functionality. Maybe we can just ignore that? Uko

July 10, 2014

Font popup logic :(

by stepharo

Hi all I'm going over PluggableListMorph extension to see if we can absorb a bit the extension. PluggableListMorph>>setListFont "set the font for the list" StandardFonts chooseFontWithTitle: 'Choose the font for this list' translated for: self setSelector: #font: getSelector: #font This shows to me that font should be managed via settings. Stef

July 10, 2014

Re: [Pharo-dev] [Website] added explicit links for Pharo4

by Sven Van Caekenberghe

Very nice ! On 10 Jul 2014, at 13:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I changed the end of the page a bit to mention explicitly Pharo4 and a link to the latest image and CI Server: > > http://pharo.org/download > > I fixed the ZeroConf section to point people to read the page. > > Marcus

July 10, 2014