June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Norbert Hartl

> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon <tim(a)testit.works>: > > Hi - yes Iâm pleased you check out the entire tree, although currently itâs a bit confusing that you do (fortunately this does give the possibility that we can checkout images and other resources that an Pharo application might rely on - without having to resort to the Seaside FileLibrary trick). > > However my concrete case was that I have a gitlab ci pipeline and next to my src directory in my project I have a config directory that has some Nginx config for my teapot app. If I add a teapot route, I also need to adjust that config and check both changes in together. I canât easily do that now? > > I can modify /config/app.nginx either in another app (intellij) or even in the simple Pharo text editor, and the I can add my new route in my DemoApp>>createRoutes method but how do I check them in together so my pipeline will build atomically? > > Iceberg hasnât written out the changes yet, so IntelliJ canât see them to do a commit, and iceberg ignores the parallel /config directory (that it checked out). So itâs a catch 22. > > This is why I suggested maybe we could specify safer (textual) directories that iceberg might also checkin? OR we have a Stage command in iceberg that does everything that commit does up to the point of actually writing to the repo - then I could jump to IntelliJ and do the final commit there and use its tools to manage non Pharo stuff (until we can build more)? > > Does this make sense? > I donât understand why you are so eager to have everything into one commit. Usually the tension is rather have small commits. What is the problem of having two commits for this? Norbert > As an aside - Iâd really like to checkin in the play-xxx directories (the .ph files) as there is often useful playground stuff Iâd like to access on my home computer. We canât do that easily at the moment either. > > Tim > > Sent from my iPhone > > On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > >> Just to complement Esteban's answer: >> >> - Iceberg checks out in disk more than the src directory because you **may** want to edit files from the command line, and after long discussions we did not want to forbid that. >> Actually, just to put everybody in perspective, at first the idea was to not have a working copy in disk at all, but just hit to the blob. >> Imagine is nowadays we are a bit alien, that would have been worst :) >> >> - About checking in files. I'd like to understand what you mean exactly. >> - Do you want to load them into memory? >> This would be the "more consistent" way to do it, following the "the image it its own working copy" metaphore. >> This would allow us to, for example, share an image and transparently share resources with it (without requiring to clone). >> But this would have some impact in memory consumption and add stress to the GC, right? >> >> - Or do you mean to ask like any other Git client and show you the file differences between the working copy and the git index? >> The problem with this approach is that we will have some treatment for pharo code and some different treatment for non-code... >> If I do a change to a class, the change is kept in the image. But if I do a change to a file, that change is not kept in the image! >> >> Also, as Esteban says, having an IDE with support for files would mean that we would need good tools to edit in-memory files (not only text files, right? but also any kind of binary file...) >> >> So far we cover the bare minimum that allows us to *not lose* changes :) >> >> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by step. >> >> Fair enough - its pretty cool weâve got this far, and I guess the onus is on the rest of us to learn more about how its done and see if we can contribute more somehow. I really appreciate the love youâve already put into this - it works far better than I think we even realised it could. >> >> Tim >> >> >> >> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> > >> > >> > >> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> >> >> Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? >> >> >> >> Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? >> >> >> >> Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) >> >> >> >> OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? >> >> >> >> I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? >> > >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by step. >> > >> >> >> >> Tim >> >> >> >> Sent from my iPhone >> >> >> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> >> >>> hi, >> >>> >> >>> >> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >>>> >> >>>> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >> >>>> >> >>>> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >> >>>> >> >>>> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). >> >>> >> >>> workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. >> >>> what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. >> >>> >> >>> at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. >> >>> So, instead having this picture in mind: >> >>> >> >>> Image -> Disk -> Git blob (database) >> >>> >> >>> you need to have this other: >> >>> >> >>> Image \ >> >>> Git blob (database) >> >>> Disk / >> >>> >> >>> >> >>> you will see as soon as you change the mental image, your problems are gone ;) >> >>> >> >>> cheers! >> >>> Esteban >> >>> >> >>> ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. >> >>> >> >>>> >> >>>> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >> >>>> >> >>>> It strikes me that this is the kind of thing that git integration should bring to us? >> >>>> >> >>>> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >> >>>> >> >>>> Tim >> >>> >> >>> >> >> >> >> >> > >> > >> >> >> >> >> -- >> >> Guille Polito >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> CRIStAL - UMR 9189 >> French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> >> >> Web: http://guillep.github.io <http://guillep.github.io/> >> Phone: +33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Guillermo Polito

BTW, addFilesToIndex: will not add files to the git index immediately, it will do it just before a commit only. On Thu, Jun 14, 2018 at 11:03 AM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > addFileToIndex: and addFilesToIndex: are still there... > > We of course have support for changing and committing arbitrary files > (actually, pharo code at the end are just arbitrary files!). The difficult > part is to bring a consistent UI to life for it... > > On Thu, Jun 14, 2018 at 10:43 AM Tim Mackinnon <tim(a)testit.works> wrote: > >> Ooooh - I didnât know about #addToIndex: that sounds like a possible >> workaround to my problem (but not a generic solution though). >> >> BTW - I donât want this to be a criticism, Iâm loving the tools and their >> possibilities! >> >> Tim >> >> Sent from my iPhone >> >> On 14 Jun 2018, at 09:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Wait... so it is no longer possible to #addtoIndex: external files from >> Pharo? I thought that this functionality was supposed to be preserved. >> >> Peter >> >> On Thu, Jun 14, 2018 at 10:30 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> >>> Hi - yes Iâm pleased you check out the entire tree, although currently >>> itâs a bit confusing that you do (fortunately this does give the >>> possibility that we can checkout images and other resources that an Pharo >>> application might rely on - without having to resort to the Seaside >>> FileLibrary trick). >>> >>> However my concrete case was that I have a gitlab ci pipeline and next >>> to my src directory in my project I have a config directory that has some >>> Nginx config for my teapot app. If I add a teapot route, I also need to >>> adjust that config and check both changes in together. I canât easily do >>> that now? >>> >>> I can modify /config/app.nginx either in another app (intellij) or even >>> in the simple Pharo text editor, and the I can add my new route in my >>> DemoApp>>createRoutes method but how do I check them in together so my >>> pipeline will build atomically? >>> >>> Iceberg hasnât written out the changes yet, so IntelliJ canât see them >>> to do a commit, and iceberg ignores the parallel /config directory (that it >>> checked out). So itâs a catch 22. >>> >>> This is why I suggested maybe we could specify safer (textual) >>> directories that iceberg might also checkin? OR we have a Stage command in >>> iceberg that does everything that commit does up to the point of actually >>> writing to the repo - then I could jump to IntelliJ and do the final commit >>> there and use its tools to manage non Pharo stuff (until we can build more)? >>> >>> Does this make sense? >>> >>> As an aside - Iâd really like to checkin in the play-xxx directories >>> (the .ph files) as there is often useful playground stuff Iâd like to >>> access on my home computer. We canât do that easily at the moment either. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>> On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>> Just to complement Esteban's answer: >>> >>> - Iceberg checks out in disk more than the src directory because you >>> **may** want to edit files from the command line, and after long >>> discussions we did not want to forbid that. >>> Actually, just to put everybody in perspective, at first the idea was to >>> not have a working copy in disk at all, but just hit to the blob. >>> Imagine is nowadays we are a bit alien, that would have been worst :) >>> >>> - About checking in files. I'd like to understand what you mean exactly. >>> - Do you want to load them into memory? >>> This would be the "more consistent" way to do it, following the "the >>> image it its own working copy" metaphore. >>> This would allow us to, for example, share an image and >>> transparently share resources with it (without requiring to clone). >>> But this would have some impact in memory consumption and add stress >>> to the GC, right? >>> >>> - Or do you mean to ask like any other Git client and show you the >>> file differences between the working copy and the git index? >>> The problem with this approach is that we will have some treatment >>> for pharo code and some different treatment for non-code... >>> If I do a change to a class, the change is kept in the image. But if >>> I do a change to a file, that change is not kept in the image! >>> >>> Also, as Esteban says, having an IDE with support for files would mean >>> that we would need good tools to edit in-memory files (not only text files, >>> right? but also any kind of binary file...) >>> >>> So far we cover the bare minimum that allows us to *not lose* changes :) >>> >>> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: >>> >>>> >>>> > yeahâ¦ but is a lot of work and no time just right now. >>>> > long term, it would be cool to manage everything from iceberg. >>>> > but reality check, is a huge amount of work so it has to come step by >>>> step. >>>> >>>> Fair enough - its pretty cool weâve got this far, and I guess the onus >>>> is on the rest of us to learn more about how its done and see if we can >>>> contribute more somehow. I really appreciate the love youâve already put >>>> into this - it works far better than I think we even realised it could. >>>> >>>> Tim >>>> >>>> >>>> >>>> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> > >>>> > >>>> > >>>> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >> >>>> >> Esteban - so I don't then understand why iceberg (usefully in my >>>> view) checks out more than the src directory, if itâs only focusing on the >>>> Pharo blob? >>>> >> >>>> >> Iâm guessing that by knowing where the src is, you are just >>>> committing that part of the tree with libgit? >>>> >> >>>> >> Perhaps from a pragmatic first step you might consider letting us >>>> add a second safe resources directory that you could check in atomically as >>>> well (on the understanding all bets are off if it goes wrong?) >>>> >> >>>> >> OR could we have a check in mode does all the add/remove operations >>>> and writes to disk but then letâs you drop to the command line/other tool >>>> to add any other files and do the final commit? >>>> >> >>>> >> I just feel like you/we are so close to something that works a bit >>>> more broadly and embrace the wider world.? >>>> > >>>> > yeahâ¦ but is a lot of work and no time just right now. >>>> > long term, it would be cool to manage everything from iceberg. >>>> > but reality check, is a huge amount of work so it has to come step by >>>> step. >>>> > >>>> >> >>>> >> Tim >>>> >> >>>> >> Sent from my iPhone >>>> >> >>>> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> >>>> wrote: >>>> >>> >>>> >>> hi, >>>> >>> >>>> >>> >>>> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> >>>> >>>> Hi - my second attempt at using Pharo with Git has proven very >>>> satisfying (I saw the potential in phase 1, but it was often difficult to >>>> understand what was happening and the workflow to use). >>>> >>>> >>>> >>>> One thing that has come up a few times for me however - and its >>>> something that using git nicely highlights, there are many non-smalltalk >>>> assets in my project that donât need to live in the image (like Seaside >>>> FileLibraries were trying to do) but do need to be versioned and be part of >>>> my project. Common examples are server config files, images and even the >>>> playground history files that are useful to pull up when on another >>>> computer. >>>> >>>> >>>> >>>> It seems that while Iceberg does check out a full project, if I >>>> change any of the files outside of the src directory (like edit a .txt file >>>> using the crude Pharo file editor), those changes donât get committed when >>>> I do a checkin? Is this on purpose? It makes the workflow a bit trickier to >>>> do an atomic commit of a piece of work - and Iâm not clear whether this is >>>> a conscious thing, or an MVP thing (and it will come later). >>>> >>> >>>> >>> workflow is tricker because you are expecting iceberg to talk with >>>> the local working copy and to handle that WC. >>>> >>> what happens in fact is different: iceberg treats the image as a >>>> working copy itself (it has its own âstageâ area) and what you have in disk >>>> is like a separated WC. >>>> >>> >>>> >>> at least, this is the metaphor we are using now, because we cannot >>>> realistically handle/control what is in disk since it can be anything. >>>> >>> So, instead having this picture in mind: >>>> >>> >>>> >>> Image -> Disk -> Git blob (database) >>>> >>> >>>> >>> you need to have this other: >>>> >>> >>>> >>> Image \ >>>> >>> Git blob (database) >>>> >>> Disk / >>>> >>> >>>> >>> >>>> >>> you will see as soon as you change the mental image, your problems >>>> are gone ;) >>>> >>> >>>> >>> cheers! >>>> >>> Esteban >>>> >>> >>>> >>> ps: diagram before is not exactly as it is since the image actually >>>> writes into disk first, but this is an implementation detail we would like >>>> to remove in the future, even. >>>> >>> >>>> >>>> >>>> >>>> As mentioned above, I was also thinking it would be nice if I >>>> could checkin some of the play-xxxx/*.sh files to essentially keep some of >>>> that history synced between environments (or team members?). >>>> >>>> >>>> >>>> It strikes me that this is the kind of thing that git integration >>>> should bring to us? >>>> >>>> >>>> >>>> I can overlay my copy of IntelliJ on top of my local iceberg >>>> directory and then use it for checkins - but then I still have the atomic >>>> problem, as its only when I commit that tonel files are written out onto >>>> the file system for me to checkin along with any other assets Iâve changed. >>>> Does anyone else have a good workflow for this? What do you guys do? >>>> >>>> >>>> >>>> Tim >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 >>> >>> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Guillermo Polito

addFileToIndex: and addFilesToIndex: are still there... We of course have support for changing and committing arbitrary files (actually, pharo code at the end are just arbitrary files!). The difficult part is to bring a consistent UI to life for it... On Thu, Jun 14, 2018 at 10:43 AM Tim Mackinnon <tim(a)testit.works> wrote: > Ooooh - I didnât know about #addToIndex: that sounds like a possible > workaround to my problem (but not a generic solution though). > > BTW - I donât want this to be a criticism, Iâm loving the tools and their > possibilities! > > Tim > > Sent from my iPhone > > On 14 Jun 2018, at 09:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Wait... so it is no longer possible to #addtoIndex: external files from > Pharo? I thought that this functionality was supposed to be preserved. > > Peter > > On Thu, Jun 14, 2018 at 10:30 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - yes Iâm pleased you check out the entire tree, although currently >> itâs a bit confusing that you do (fortunately this does give the >> possibility that we can checkout images and other resources that an Pharo >> application might rely on - without having to resort to the Seaside >> FileLibrary trick). >> >> However my concrete case was that I have a gitlab ci pipeline and next to >> my src directory in my project I have a config directory that has some >> Nginx config for my teapot app. If I add a teapot route, I also need to >> adjust that config and check both changes in together. I canât easily do >> that now? >> >> I can modify /config/app.nginx either in another app (intellij) or even >> in the simple Pharo text editor, and the I can add my new route in my >> DemoApp>>createRoutes method but how do I check them in together so my >> pipeline will build atomically? >> >> Iceberg hasnât written out the changes yet, so IntelliJ canât see them to >> do a commit, and iceberg ignores the parallel /config directory (that it >> checked out). So itâs a catch 22. >> >> This is why I suggested maybe we could specify safer (textual) >> directories that iceberg might also checkin? OR we have a Stage command in >> iceberg that does everything that commit does up to the point of actually >> writing to the repo - then I could jump to IntelliJ and do the final commit >> there and use its tools to manage non Pharo stuff (until we can build more)? >> >> Does this make sense? >> >> As an aside - Iâd really like to checkin in the play-xxx directories (the >> .ph files) as there is often useful playground stuff Iâd like to access on >> my home computer. We canât do that easily at the moment either. >> >> Tim >> >> Sent from my iPhone >> >> On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> Just to complement Esteban's answer: >> >> - Iceberg checks out in disk more than the src directory because you >> **may** want to edit files from the command line, and after long >> discussions we did not want to forbid that. >> Actually, just to put everybody in perspective, at first the idea was to >> not have a working copy in disk at all, but just hit to the blob. >> Imagine is nowadays we are a bit alien, that would have been worst :) >> >> - About checking in files. I'd like to understand what you mean exactly. >> - Do you want to load them into memory? >> This would be the "more consistent" way to do it, following the "the >> image it its own working copy" metaphore. >> This would allow us to, for example, share an image and transparently >> share resources with it (without requiring to clone). >> But this would have some impact in memory consumption and add stress >> to the GC, right? >> >> - Or do you mean to ask like any other Git client and show you the file >> differences between the working copy and the git index? >> The problem with this approach is that we will have some treatment >> for pharo code and some different treatment for non-code... >> If I do a change to a class, the change is kept in the image. But if >> I do a change to a file, that change is not kept in the image! >> >> Also, as Esteban says, having an IDE with support for files would mean >> that we would need good tools to edit in-memory files (not only text files, >> right? but also any kind of binary file...) >> >> So far we cover the bare minimum that allows us to *not lose* changes :) >> >> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: >> >>> >>> > yeahâ¦ but is a lot of work and no time just right now. >>> > long term, it would be cool to manage everything from iceberg. >>> > but reality check, is a huge amount of work so it has to come step by >>> step. >>> >>> Fair enough - its pretty cool weâve got this far, and I guess the onus >>> is on the rest of us to learn more about how its done and see if we can >>> contribute more somehow. I really appreciate the love youâve already put >>> into this - it works far better than I think we even realised it could. >>> >>> Tim >>> >>> >>> >>> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> > >>> > >>> > >>> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >>> >> >>> >> Esteban - so I don't then understand why iceberg (usefully in my >>> view) checks out more than the src directory, if itâs only focusing on the >>> Pharo blob? >>> >> >>> >> Iâm guessing that by knowing where the src is, you are just >>> committing that part of the tree with libgit? >>> >> >>> >> Perhaps from a pragmatic first step you might consider letting us add >>> a second safe resources directory that you could check in atomically as >>> well (on the understanding all bets are off if it goes wrong?) >>> >> >>> >> OR could we have a check in mode does all the add/remove operations >>> and writes to disk but then letâs you drop to the command line/other tool >>> to add any other files and do the final commit? >>> >> >>> >> I just feel like you/we are so close to something that works a bit >>> more broadly and embrace the wider world.? >>> > >>> > yeahâ¦ but is a lot of work and no time just right now. >>> > long term, it would be cool to manage everything from iceberg. >>> > but reality check, is a huge amount of work so it has to come step by >>> step. >>> > >>> >> >>> >> Tim >>> >> >>> >> Sent from my iPhone >>> >> >>> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >>> >>> >>> hi, >>> >>> >>> >>> >>> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>>> >>> >>>> Hi - my second attempt at using Pharo with Git has proven very >>> satisfying (I saw the potential in phase 1, but it was often difficult to >>> understand what was happening and the workflow to use). >>> >>>> >>> >>>> One thing that has come up a few times for me however - and its >>> something that using git nicely highlights, there are many non-smalltalk >>> assets in my project that donât need to live in the image (like Seaside >>> FileLibraries were trying to do) but do need to be versioned and be part of >>> my project. Common examples are server config files, images and even the >>> playground history files that are useful to pull up when on another >>> computer. >>> >>>> >>> >>>> It seems that while Iceberg does check out a full project, if I >>> change any of the files outside of the src directory (like edit a .txt file >>> using the crude Pharo file editor), those changes donât get committed when >>> I do a checkin? Is this on purpose? It makes the workflow a bit trickier to >>> do an atomic commit of a piece of work - and Iâm not clear whether this is >>> a conscious thing, or an MVP thing (and it will come later). >>> >>> >>> >>> workflow is tricker because you are expecting iceberg to talk with >>> the local working copy and to handle that WC. >>> >>> what happens in fact is different: iceberg treats the image as a >>> working copy itself (it has its own âstageâ area) and what you have in disk >>> is like a separated WC. >>> >>> >>> >>> at least, this is the metaphor we are using now, because we cannot >>> realistically handle/control what is in disk since it can be anything. >>> >>> So, instead having this picture in mind: >>> >>> >>> >>> Image -> Disk -> Git blob (database) >>> >>> >>> >>> you need to have this other: >>> >>> >>> >>> Image \ >>> >>> Git blob (database) >>> >>> Disk / >>> >>> >>> >>> >>> >>> you will see as soon as you change the mental image, your problems >>> are gone ;) >>> >>> >>> >>> cheers! >>> >>> Esteban >>> >>> >>> >>> ps: diagram before is not exactly as it is since the image actually >>> writes into disk first, but this is an implementation detail we would like >>> to remove in the future, even. >>> >>> >>> >>>> >>> >>>> As mentioned above, I was also thinking it would be nice if I could >>> checkin some of the play-xxxx/*.sh files to essentially keep some of that >>> history synced between environments (or team members?). >>> >>>> >>> >>>> It strikes me that this is the kind of thing that git integration >>> should bring to us? >>> >>>> >>> >>>> I can overlay my copy of IntelliJ on top of my local iceberg >>> directory and then use it for checkins - but then I still have the atomic >>> problem, as its only when I commit that tonel files are written out onto >>> the file system for me to checkin along with any other assets Iâve changed. >>> Does anyone else have a good workflow for this? What do you guys do? >>> >>>> >>> >>>> Tim >>> >>> >>> >>> >>> >> >>> >> >>> > >>> > >>> >>> >>> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

Ooooh - I didnât know about #addToIndex: that sounds like a possible workaround to my problem (but not a generic solution though). BTW - I donât want this to be a criticism, Iâm loving the tools and their possibilities! Tim Sent from my iPhone > On 14 Jun 2018, at 09:36, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Wait... so it is no longer possible to #addtoIndex: external files from Pharo? I thought that this functionality was supposed to be preserved. > > Peter > >> On Thu, Jun 14, 2018 at 10:30 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> Hi - yes Iâm pleased you check out the entire tree, although currently itâs a bit confusing that you do (fortunately this does give the possibility that we can checkout images and other resources that an Pharo application might rely on - without having to resort to the Seaside FileLibrary trick). >> >> However my concrete case was that I have a gitlab ci pipeline and next to my src directory in my project I have a config directory that has some Nginx config for my teapot app. If I add a teapot route, I also need to adjust that config and check both changes in together. I canât easily do that now? >> >> I can modify /config/app.nginx either in another app (intellij) or even in the simple Pharo text editor, and the I can add my new route in my DemoApp>>createRoutes method but how do I check them in together so my pipeline will build atomically? >> >> Iceberg hasnât written out the changes yet, so IntelliJ canât see them to do a commit, and iceberg ignores the parallel /config directory (that it checked out). So itâs a catch 22. >> >> This is why I suggested maybe we could specify safer (textual) directories that iceberg might also checkin? OR we have a Stage command in iceberg that does everything that commit does up to the point of actually writing to the repo - then I could jump to IntelliJ and do the final commit there and use its tools to manage non Pharo stuff (until we can build more)? >> >> Does this make sense? >> >> As an aside - Iâd really like to checkin in the play-xxx directories (the .ph files) as there is often useful playground stuff Iâd like to access on my home computer. We canât do that easily at the moment either. >> >> Tim >> >> Sent from my iPhone >> >>> On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Just to complement Esteban's answer: >>> >>> - Iceberg checks out in disk more than the src directory because you **may** want to edit files from the command line, and after long discussions we did not want to forbid that. >>> Actually, just to put everybody in perspective, at first the idea was to not have a working copy in disk at all, but just hit to the blob. >>> Imagine is nowadays we are a bit alien, that would have been worst :) >>> >>> - About checking in files. I'd like to understand what you mean exactly. >>> - Do you want to load them into memory? >>> This would be the "more consistent" way to do it, following the "the image it its own working copy" metaphore. >>> This would allow us to, for example, share an image and transparently share resources with it (without requiring to clone). >>> But this would have some impact in memory consumption and add stress to the GC, right? >>> >>> - Or do you mean to ask like any other Git client and show you the file differences between the working copy and the git index? >>> The problem with this approach is that we will have some treatment for pharo code and some different treatment for non-code... >>> If I do a change to a class, the change is kept in the image. But if I do a change to a file, that change is not kept in the image! >>> >>> Also, as Esteban says, having an IDE with support for files would mean that we would need good tools to edit in-memory files (not only text files, right? but also any kind of binary file...) >>> >>> So far we cover the bare minimum that allows us to *not lose* changes :) >>> >>>> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> > yeahâ¦ but is a lot of work and no time just right now. >>>> > long term, it would be cool to manage everything from iceberg. >>>> > but reality check, is a huge amount of work so it has to come step by step. >>>> >>>> Fair enough - its pretty cool weâve got this far, and I guess the onus is on the rest of us to learn more about how its done and see if we can contribute more somehow. I really appreciate the love youâve already put into this - it works far better than I think we even realised it could. >>>> >>>> Tim >>>> >>>> >>>> >>>> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> > >>>> > >>>> > >>>> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >> >>>> >> Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? >>>> >> >>>> >> Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? >>>> >> >>>> >> Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) >>>> >> >>>> >> OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? >>>> >> >>>> >> I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? >>>> > >>>> > yeahâ¦ but is a lot of work and no time just right now. >>>> > long term, it would be cool to manage everything from iceberg. >>>> > but reality check, is a huge amount of work so it has to come step by step. >>>> > >>>> >> >>>> >> Tim >>>> >> >>>> >> Sent from my iPhone >>>> >> >>>> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>> >>>> >>> hi, >>>> >>> >>>> >>> >>>> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> >>>> >>>> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >>>> >>>> >>>> >>>> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >>>> >>>> >>>> >>>> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). >>>> >>> >>>> >>> workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. >>>> >>> what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. >>>> >>> >>>> >>> at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. >>>> >>> So, instead having this picture in mind: >>>> >>> >>>> >>> Image -> Disk -> Git blob (database) >>>> >>> >>>> >>> you need to have this other: >>>> >>> >>>> >>> Image \ >>>> >>> Git blob (database) >>>> >>> Disk / >>>> >>> >>>> >>> >>>> >>> you will see as soon as you change the mental image, your problems are gone ;) >>>> >>> >>>> >>> cheers! >>>> >>> Esteban >>>> >>> >>>> >>> ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. >>>> >>> >>>> >>>> >>>> >>>> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >>>> >>>> >>>> >>>> It strikes me that this is the kind of thing that git integration should bring to us? >>>> >>>> >>>> >>>> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >>>> >>>> >>>> >>>> Tim >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>> >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Peter UhnÃ¡k

Wait... so it is no longer possible to #addtoIndex: external files from Pharo? I thought that this functionality was supposed to be preserved. Peter On Thu, Jun 14, 2018 at 10:30 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi - yes Iâm pleased you check out the entire tree, although currently > itâs a bit confusing that you do (fortunately this does give the > possibility that we can checkout images and other resources that an Pharo > application might rely on - without having to resort to the Seaside > FileLibrary trick). > > However my concrete case was that I have a gitlab ci pipeline and next to > my src directory in my project I have a config directory that has some > Nginx config for my teapot app. If I add a teapot route, I also need to > adjust that config and check both changes in together. I canât easily do > that now? > > I can modify /config/app.nginx either in another app (intellij) or even in > the simple Pharo text editor, and the I can add my new route in my > DemoApp>>createRoutes method but how do I check them in together so my > pipeline will build atomically? > > Iceberg hasnât written out the changes yet, so IntelliJ canât see them to > do a commit, and iceberg ignores the parallel /config directory (that it > checked out). So itâs a catch 22. > > This is why I suggested maybe we could specify safer (textual) directories > that iceberg might also checkin? OR we have a Stage command in iceberg that > does everything that commit does up to the point of actually writing to the > repo - then I could jump to IntelliJ and do the final commit there and use > its tools to manage non Pharo stuff (until we can build more)? > > Does this make sense? > > As an aside - Iâd really like to checkin in the play-xxx directories (the > .ph files) as there is often useful playground stuff Iâd like to access on > my home computer. We canât do that easily at the moment either. > > Tim > > Sent from my iPhone > > On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Just to complement Esteban's answer: > > - Iceberg checks out in disk more than the src directory because you > **may** want to edit files from the command line, and after long > discussions we did not want to forbid that. > Actually, just to put everybody in perspective, at first the idea was to > not have a working copy in disk at all, but just hit to the blob. > Imagine is nowadays we are a bit alien, that would have been worst :) > > - About checking in files. I'd like to understand what you mean exactly. > - Do you want to load them into memory? > This would be the "more consistent" way to do it, following the "the > image it its own working copy" metaphore. > This would allow us to, for example, share an image and transparently > share resources with it (without requiring to clone). > But this would have some impact in memory consumption and add stress > to the GC, right? > > - Or do you mean to ask like any other Git client and show you the file > differences between the working copy and the git index? > The problem with this approach is that we will have some treatment for > pharo code and some different treatment for non-code... > If I do a change to a class, the change is kept in the image. But if I > do a change to a file, that change is not kept in the image! > > Also, as Esteban says, having an IDE with support for files would mean > that we would need good tools to edit in-memory files (not only text files, > right? but also any kind of binary file...) > > So far we cover the bare minimum that allows us to *not lose* changes :) > > On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by >> step. >> >> Fair enough - its pretty cool weâve got this far, and I guess the onus is >> on the rest of us to learn more about how its done and see if we can >> contribute more somehow. I really appreciate the love youâve already put >> into this - it works far better than I think we even realised it could. >> >> Tim >> >> >> >> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> > >> > >> > >> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >> >> >> >> Esteban - so I don't then understand why iceberg (usefully in my view) >> checks out more than the src directory, if itâs only focusing on the Pharo >> blob? >> >> >> >> Iâm guessing that by knowing where the src is, you are just committing >> that part of the tree with libgit? >> >> >> >> Perhaps from a pragmatic first step you might consider letting us add >> a second safe resources directory that you could check in atomically as >> well (on the understanding all bets are off if it goes wrong?) >> >> >> >> OR could we have a check in mode does all the add/remove operations >> and writes to disk but then letâs you drop to the command line/other tool >> to add any other files and do the final commit? >> >> >> >> I just feel like you/we are so close to something that works a bit >> more broadly and embrace the wider world.? >> > >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by >> step. >> > >> >> >> >> Tim >> >> >> >> Sent from my iPhone >> >> >> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >> >>> hi, >> >>> >> >>> >> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >> >>>> >> >>>> Hi - my second attempt at using Pharo with Git has proven very >> satisfying (I saw the potential in phase 1, but it was often difficult to >> understand what was happening and the workflow to use). >> >>>> >> >>>> One thing that has come up a few times for me however - and its >> something that using git nicely highlights, there are many non-smalltalk >> assets in my project that donât need to live in the image (like Seaside >> FileLibraries were trying to do) but do need to be versioned and be part of >> my project. Common examples are server config files, images and even the >> playground history files that are useful to pull up when on another >> computer. >> >>>> >> >>>> It seems that while Iceberg does check out a full project, if I >> change any of the files outside of the src directory (like edit a .txt file >> using the crude Pharo file editor), those changes donât get committed when >> I do a checkin? Is this on purpose? It makes the workflow a bit trickier to >> do an atomic commit of a piece of work - and Iâm not clear whether this is >> a conscious thing, or an MVP thing (and it will come later). >> >>> >> >>> workflow is tricker because you are expecting iceberg to talk with >> the local working copy and to handle that WC. >> >>> what happens in fact is different: iceberg treats the image as a >> working copy itself (it has its own âstageâ area) and what you have in disk >> is like a separated WC. >> >>> >> >>> at least, this is the metaphor we are using now, because we cannot >> realistically handle/control what is in disk since it can be anything. >> >>> So, instead having this picture in mind: >> >>> >> >>> Image -> Disk -> Git blob (database) >> >>> >> >>> you need to have this other: >> >>> >> >>> Image \ >> >>> Git blob (database) >> >>> Disk / >> >>> >> >>> >> >>> you will see as soon as you change the mental image, your problems >> are gone ;) >> >>> >> >>> cheers! >> >>> Esteban >> >>> >> >>> ps: diagram before is not exactly as it is since the image actually >> writes into disk first, but this is an implementation detail we would like >> to remove in the future, even. >> >>> >> >>>> >> >>>> As mentioned above, I was also thinking it would be nice if I could >> checkin some of the play-xxxx/*.sh files to essentially keep some of that >> history synced between environments (or team members?). >> >>>> >> >>>> It strikes me that this is the kind of thing that git integration >> should bring to us? >> >>>> >> >>>> I can overlay my copy of IntelliJ on top of my local iceberg >> directory and then use it for checkins - but then I still have the atomic >> problem, as its only when I commit that tonel files are written out onto >> the file system for me to checkin along with any other assets Iâve changed. >> Does anyone else have a good workflow for this? What do you guys do? >> >>>> >> >>>> Tim >> >>> >> >>> >> >> >> >> >> > >> > >> >> >> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > >

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

Hi - yes Iâm pleased you check out the entire tree, although currently itâs a bit confusing that you do (fortunately this does give the possibility that we can checkout images and other resources that an Pharo application might rely on - without having to resort to the Seaside FileLibrary trick). However my concrete case was that I have a gitlab ci pipeline and next to my src directory in my project I have a config directory that has some Nginx config for my teapot app. If I add a teapot route, I also need to adjust that config and check both changes in together. I canât easily do that now? I can modify /config/app.nginx either in another app (intellij) or even in the simple Pharo text editor, and the I can add my new route in my DemoApp>>createRoutes method but how do I check them in together so my pipeline will build atomically? Iceberg hasnât written out the changes yet, so IntelliJ canât see them to do a commit, and iceberg ignores the parallel /config directory (that it checked out). So itâs a catch 22. This is why I suggested maybe we could specify safer (textual) directories that iceberg might also checkin? OR we have a Stage command in iceberg that does everything that commit does up to the point of actually writing to the repo - then I could jump to IntelliJ and do the final commit there and use its tools to manage non Pharo stuff (until we can build more)? Does this make sense? As an aside - Iâd really like to checkin in the play-xxx directories (the .ph files) as there is often useful playground stuff Iâd like to access on my home computer. We canât do that easily at the moment either. Tim Sent from my iPhone > On 14 Jun 2018, at 09:12, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Just to complement Esteban's answer: > > - Iceberg checks out in disk more than the src directory because you **may** want to edit files from the command line, and after long discussions we did not want to forbid that. > Actually, just to put everybody in perspective, at first the idea was to not have a working copy in disk at all, but just hit to the blob. > Imagine is nowadays we are a bit alien, that would have been worst :) > > - About checking in files. I'd like to understand what you mean exactly. > - Do you want to load them into memory? > This would be the "more consistent" way to do it, following the "the image it its own working copy" metaphore. > This would allow us to, for example, share an image and transparently share resources with it (without requiring to clone). > But this would have some impact in memory consumption and add stress to the GC, right? > > - Or do you mean to ask like any other Git client and show you the file differences between the working copy and the git index? > The problem with this approach is that we will have some treatment for pharo code and some different treatment for non-code... > If I do a change to a class, the change is kept in the image. But if I do a change to a file, that change is not kept in the image! > > Also, as Esteban says, having an IDE with support for files would mean that we would need good tools to edit in-memory files (not only text files, right? but also any kind of binary file...) > > So far we cover the bare minimum that allows us to *not lose* changes :) > >> On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: >> >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by step. >> >> Fair enough - its pretty cool weâve got this far, and I guess the onus is on the rest of us to learn more about how its done and see if we can contribute more somehow. I really appreciate the love youâve already put into this - it works far better than I think we even realised it could. >> >> Tim >> >> >> >> > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> > >> > >> > >> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >> >> >> >> Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? >> >> >> >> Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? >> >> >> >> Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) >> >> >> >> OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? >> >> >> >> I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? >> > >> > yeahâ¦ but is a lot of work and no time just right now. >> > long term, it would be cool to manage everything from iceberg. >> > but reality check, is a huge amount of work so it has to come step by step. >> > >> >> >> >> Tim >> >> >> >> Sent from my iPhone >> >> >> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >> >>> hi, >> >>> >> >>> >> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >> >>>> >> >>>> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >> >>>> >> >>>> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >> >>>> >> >>>> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). >> >>> >> >>> workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. >> >>> what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. >> >>> >> >>> at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. >> >>> So, instead having this picture in mind: >> >>> >> >>> Image -> Disk -> Git blob (database) >> >>> >> >>> you need to have this other: >> >>> >> >>> Image \ >> >>> Git blob (database) >> >>> Disk / >> >>> >> >>> >> >>> you will see as soon as you change the mental image, your problems are gone ;) >> >>> >> >>> cheers! >> >>> Esteban >> >>> >> >>> ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. >> >>> >> >>>> >> >>>> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >> >>>> >> >>>> It strikes me that this is the kind of thing that git integration should bring to us? >> >>>> >> >>>> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >> >>>> >> >>>> Tim >> >>> >> >>> >> >> >> >> >> > >> > >> >> > > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Tim Mackinnon

Hi Guille - I have tried the repo browser with the new iceberg loaded in Pharo 6.1 and I couldnât see how it helps me? (I will make a firm point of using 7 now as I think Iâve now got a reasonable grasp of how things should work). >From the threads below - how would I find the commit with my missing class - Sean has pointed me to a git query that helps with that (and presumablyq is something we can plug into iceberg - maybe I will even take a look). Having identified the hash with the class I want - getting to it is awkward (there is no search - again pretty easy for us to plug in, but something to do) Having got to my commit - how can I retrieve one class? Maybe this is something only in Pharo 7 with Calypso? All I can see are diffs - so Iâd have to copy and paste 20 methods and a class def. doable, but painful. Iâm hoping there is a way to get a shadow copy of the commit from the tonel file and then use it to restore classes and methods? As this sounds like a decent chunk of work, Iâm guessing itâs not done yet? As a fallback, Any thoughts on why git wonât let me checkout a file from that commit? Something about the pathspec (is it mangled in some way)? And if I could restore a tonel file - would iceberg then recognise it to bring it back in, or Would I need to use some filestream foo to do that (as this would at least be a viable workaround for now)? Tim Sent from my iPhone Sent from my iPhone > On 14 Jun 2018, at 08:52, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > Regarding history, right now we have a history browser implemented as a Calypso plugin, that is open using context menu => history or the little box button on the top right of the method pane (second button from the left in the picture): > > <Screen Shot 2018-06-14 at 09.34.24.png> > > That button will nowadays only be shown if the method's package is linked to an iceberg repository. > Once you click it, you will have the entire history of the method. > > <Screen Shot 2018-06-14 at 09.47.46.png> > > With the possibility to install that version of the method (among others). > > Now, regarding the recovery of deleted classes/methods, have you tried the repository browser? > Go to Iceberg, right click on a repository and select "Repository". > You can there select a commit in history and then in the tabs below see the diff between > - your current version and the selected commit > - the selected commit and its main parent > > Of course any of these can be improved, but if you have concrete requests, it is much easier :) > > https://github.com/pharo-vcs/iceberg > > Guille > >> On Wed, Jun 13, 2018 at 11:22 PM Tim Mackinnon <tim(a)testit.works> wrote: >> Hi Sean - I tried it again, and it worked: >> >> git log --full-history -- */PrismicBlock.class* >> >> (I got my wildcard slightly wrong for tonel format) - although the beauty of the one I gave was that it shows you all deleted classes (in case you donât know the name) >> >> Iâm still confused why I canât checkout the deleted class though - damn you git, for the cryptic error: : error: pathspec 'PrismicDemo/PrismicBlock.class.st' did not match any file(s) known to git. >> >> I was hoping a quick hack to iceberg might be to OSProcess a few choice git commands to help us along while we work out better ways to do things. >> >> Tim >> >>>> On 13 Jun 2018, at 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>> >>>> Tim Mackinnon wrote >>>> I didnât quite get your fu to work >>> >>> Interesting. >>> >>> When I searched for commits affecting the deleted class SuDebianKey: >>> >>> $ git log --full-history -- */SuDebianKey.class/properties.json >>> >>> I got back a list of commits (obviously with the last chronologically being >>> the deletion): >>> >>> commit a38fbced4abec59ff9879d4c607da80dc89b6637 >>> Author: Sean DeNigris <sean(a)Seans-MBP.home> >>> Date: Mon Jan 30 17:13:58 2017 -0500 >>> >>> Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project >>> >>> commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea >>> Author: Sean DeNigris <sean(a)clipperadams.com> >>> Date: Sat Aug 20 17:14:12 2016 -0400 >>> >>> Basket O' Enhancements >>> ... >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Guillermo Polito

Just to complement Esteban's answer: - Iceberg checks out in disk more than the src directory because you **may** want to edit files from the command line, and after long discussions we did not want to forbid that. Actually, just to put everybody in perspective, at first the idea was to not have a working copy in disk at all, but just hit to the blob. Imagine is nowadays we are a bit alien, that would have been worst :) - About checking in files. I'd like to understand what you mean exactly. - Do you want to load them into memory? This would be the "more consistent" way to do it, following the "the image it its own working copy" metaphore. This would allow us to, for example, share an image and transparently share resources with it (without requiring to clone). But this would have some impact in memory consumption and add stress to the GC, right? - Or do you mean to ask like any other Git client and show you the file differences between the working copy and the git index? The problem with this approach is that we will have some treatment for pharo code and some different treatment for non-code... If I do a change to a class, the change is kept in the image. But if I do a change to a file, that change is not kept in the image! Also, as Esteban says, having an IDE with support for files would mean that we would need good tools to edit in-memory files (not only text files, right? but also any kind of binary file...) So far we cover the bare minimum that allows us to *not lose* changes :) On Wed, Jun 13, 2018 at 11:07 PM Tim Mackinnon <tim(a)testit.works> wrote: > > > yeahâ¦ but is a lot of work and no time just right now. > > long term, it would be cool to manage everything from iceberg. > > but reality check, is a huge amount of work so it has to come step by > step. > > Fair enough - its pretty cool weâve got this far, and I guess the onus is > on the rest of us to learn more about how its done and see if we can > contribute more somehow. I really appreciate the love youâve already put > into this - it works far better than I think we even realised it could. > > Tim > > > > > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > > > > >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: > >> > >> Esteban - so I don't then understand why iceberg (usefully in my view) > checks out more than the src directory, if itâs only focusing on the Pharo > blob? > >> > >> Iâm guessing that by knowing where the src is, you are just committing > that part of the tree with libgit? > >> > >> Perhaps from a pragmatic first step you might consider letting us add a > second safe resources directory that you could check in atomically as well > (on the understanding all bets are off if it goes wrong?) > >> > >> OR could we have a check in mode does all the add/remove operations and > writes to disk but then letâs you drop to the command line/other tool to > add any other files and do the final commit? > >> > >> I just feel like you/we are so close to something that works a bit more > broadly and embrace the wider world.? > > > > yeahâ¦ but is a lot of work and no time just right now. > > long term, it would be cool to manage everything from iceberg. > > but reality check, is a huge amount of work so it has to come step by > step. > > > >> > >> Tim > >> > >> Sent from my iPhone > >> > >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>> > >>> hi, > >>> > >>> > >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: > >>>> > >>>> Hi - my second attempt at using Pharo with Git has proven very > satisfying (I saw the potential in phase 1, but it was often difficult to > understand what was happening and the workflow to use). > >>>> > >>>> One thing that has come up a few times for me however - and its > something that using git nicely highlights, there are many non-smalltalk > assets in my project that donât need to live in the image (like Seaside > FileLibraries were trying to do) but do need to be versioned and be part of > my project. Common examples are server config files, images and even the > playground history files that are useful to pull up when on another > computer. > >>>> > >>>> It seems that while Iceberg does check out a full project, if I > change any of the files outside of the src directory (like edit a .txt file > using the crude Pharo file editor), those changes donât get committed when > I do a checkin? Is this on purpose? It makes the workflow a bit trickier to > do an atomic commit of a piece of work - and Iâm not clear whether this is > a conscious thing, or an MVP thing (and it will come later). > >>> > >>> workflow is tricker because you are expecting iceberg to talk with the > local working copy and to handle that WC. > >>> what happens in fact is different: iceberg treats the image as a > working copy itself (it has its own âstageâ area) and what you have in disk > is like a separated WC. > >>> > >>> at least, this is the metaphor we are using now, because we cannot > realistically handle/control what is in disk since it can be anything. > >>> So, instead having this picture in mind: > >>> > >>> Image -> Disk -> Git blob (database) > >>> > >>> you need to have this other: > >>> > >>> Image \ > >>> Git blob (database) > >>> Disk / > >>> > >>> > >>> you will see as soon as you change the mental image, your problems are > gone ;) > >>> > >>> cheers! > >>> Esteban > >>> > >>> ps: diagram before is not exactly as it is since the image actually > writes into disk first, but this is an implementation detail we would like > to remove in the future, even. > >>> > >>>> > >>>> As mentioned above, I was also thinking it would be nice if I could > checkin some of the play-xxxx/*.sh files to essentially keep some of that > history synced between environments (or team members?). > >>>> > >>>> It strikes me that this is the kind of thing that git integration > should bring to us? > >>>> > >>>> I can overlay my copy of IntelliJ on top of my local iceberg > directory and then use it for checkins - but then I still have the atomic > problem, as its only when I commit that tonel files are written out onto > the file system for me to checkin along with any other assets Iâve changed. > Does anyone else have a good workflow for this? What do you guys do? > >>>> > >>>> Tim > >>> > >>> > >> > >> > > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Guillermo Polito

Hi, Regarding history, right now we have a history browser implemented as a Calypso plugin, that is open using context menu => history or the little box button on the top right of the method pane (second button from the left in the picture): [image: Screen Shot 2018-06-14 at 09.34.24.png] That button will nowadays only be shown if the method's package is linked to an iceberg repository. Once you click it, you will have the entire history of the method. [image: Screen Shot 2018-06-14 at 09.47.46.png] With the possibility to install that version of the method (among others). Now, regarding the recovery of deleted classes/methods, have you tried the repository browser? Go to Iceberg, right click on a repository and select "Repository". You can there select a commit in history and then in the tabs below see the diff between - your current version and the selected commit - the selected commit and its main parent Of course any of these can be improved, but if you have concrete requests, it is much easier :) https://github.com/pharo-vcs/iceberg Guille On Wed, Jun 13, 2018 at 11:22 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Sean - I tried it again, and it worked: > > git log --full-history -- */PrismicBlock.class* > > (I got my wildcard slightly wrong for tonel format) - although the beauty > of the one I gave was that it shows you all deleted classes (in case you > donât know the name) > > Iâm still confused why I canât checkout the deleted class though - damn > you git, for the cryptic error: : error: pathspec 'PrismicDemo/ > PrismicBlock.class.st' did not match any file(s) known to git. > > I was hoping a quick hack to iceberg might be to OSProcess a few choice > git commands to help us along while we work out better ways to do things. > > Tim > > On 13 Jun 2018, at 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote > > I didnât quite get your fu to work > > > Interesting. > > When I searched for commits affecting the deleted class SuDebianKey: > > $ git log --full-history -- */SuDebianKey.class/properties.json > > I got back a list of commits (obviously with the last chronologically being > the deletion): > > commit a38fbced4abec59ff9879d4c607da80dc89b6637 > Author: Sean DeNigris <sean(a)Seans-MBP.home> > Date: Mon Jan 30 17:13:58 2017 -0500 > > Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project > > commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea > Author: Sean DeNigris <sean(a)clipperadams.com> > Date: Sat Aug 20 17:14:12 2016 -0400 > > Basket O' Enhancements > ... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 14, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Tim Mackinnon

Hi Sean - I tried it again, and it worked: git log --full-history -- */PrismicBlock.class* (I got my wildcard slightly wrong for tonel format) - although the beauty of the one I gave was that it shows you all deleted classes (in case you donât know the name) Iâm still confused why I canât checkout the deleted class though - damn you git, for the cryptic error: : error: pathspec 'PrismicDemo/PrismicBlock.class.st <http://prismicblock.class.st/>' did not match any file(s) known to git. I was hoping a quick hack to iceberg might be to OSProcess a few choice git commands to help us along while we work out better ways to do things. Tim > On 13 Jun 2018, at 21:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> I didnât quite get your fu to work > > Interesting. > > When I searched for commits affecting the deleted class SuDebianKey: > > $ git log --full-history -- */SuDebianKey.class/properties.json > > I got back a list of commits (obviously with the last chronologically being > the deletion): > > commit a38fbced4abec59ff9879d4c607da80dc89b6637 > Author: Sean DeNigris <sean(a)Seans-MBP.home> > Date: Mon Jan 30 17:13:58 2017 -0500 > > Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project > > commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea > Author: Sean DeNigris <sean(a)clipperadams.com> > Date: Sat Aug 20 17:14:12 2016 -0400 > > Basket O' Enhancements > ... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

June 13, 2018