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 13:12 schrieb Thierry Goubier <thierry.goubier(a)gmail.com>: > > Hi Norbert, Tim, > > 2018-06-14 11:33 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >> >> >>> 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? > > A single commit allow one to make sure that both the smalltalk code and the external resource are well in sync, and that you may not ending up in a situation were at commit j has data format v1 and smalltalk code for format v2, because it is in commit j+1 that you rewrote the data in format v2. > Yes, sure but that is only a problem if you lost control over which commit goes into action. I think the problem is in the deployment then. Putting integrity constraints on commits is IMHO the wrong level deployment granularity Norbert > I had that issue recently with a Pharo / FPGA project with a Pharo package generating state machines to be integrated in a Verilog FPGA design with C code for the drivers, the softcore in the FPGA, and test programs, and both Pharo and the C/FPGA working out of the same test data... And that whole thing getting regularly out of sync. > > IMHO: I'd model a concept of "multi-lingual projet" for that sort of things, where one can list, in Pharo, Monticello packages and external files or directories. Whatever the technology you use (OSProcess, libgit, whatever...) it is easy then to commit all this in a single pass. On a per-package basis, I'd see the package manifest as a suitable place for listing external resources. On a per-project basis, a possible place could be the manifest for the BaselineOf the project. > > Thierry > >> >> 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> 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 15, 2018

Re: [Pharo-users] [ann] gt documenter

by Tudor Girba

Hi, I am happy you like it. Fonts should work with a Pharo 64b installation on Linux, including Manjaro. Can you confirm that you use a Pharo 64bit and that it does not work? If yes, can you describe how you are installing Pharo and GToolkit? Markdown is certainly interesting, but it is not our focus at this point. We are building on top of Pillar. There are several reasons for it, two of them being: 1. To build the experience we want to, we need deep control over the markup language and Pillar provides that in Pharo. 2. Pillar is the de facto documentation markup used in Pharo, and our primary focus is to support new kinds of development workflows in this environment, including handling documentation. GT 2nd generation will indeed not be part of Pharo 7, but will be loadable in it. Cheers, Doru > On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Cool! I hope to see how this could be integrated in Grafoscopio once Documenter is better integrated with Pharo, for example addressing the font issues already reported in the mailing list on Manjaro Linux (64 bits) and in the thread at [1] and also the Markdown integration possibilities (which are never answered). > [1] https://twitter.com/feenkcom/status/996310432225820672 > > I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to use it in a more confident day to day fashion. > > Keep the interesting work. > > Cheers, > > Offray > > On 13/06/18 15:57, Tudor Girba wrote: >> Hi, >> >> We are happy to announce a new leap of GToolkit Documenter, the tool for manipulating live documents directly in the development environment: >> https://github.com/feenkcom/gtoolkit-documenter >> >> Documenter is part of the second generation GToolkit project, it is based on Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka. >> >> Attached you can see a preview of how documents look like: >> >> <gt-documenter.png> >> >> At its core it offers a live editor for manipulating Pillar documents. The interaction happens seamlessly directly in the text editor, and it can be combined with different types of previews to serve several classes of use cases: >> â¢ code documentation >> â¢ tutorials >> â¢ interactive data notebook >> >> >> Code documentation >> ---- >> Documenter complements the GToolkit Examples engine to redefine code documentation. When practicing example-driven development, examples get written as part of the typical development. Once examples exist, they can be quickly put together in a document to form documentation. For example, the linked picture shows the comment of a class containing a visual explanation: >> https://twitter.com/feenkcom/status/973899862482866176 >> >> You can see a live example of documentation by inspecting the following snippet: >> GtDocumenter editorForText: BrToggleExamples comment. >> >> >> Tutorials: >> ---- >> Documenter offers a new experience of writing tutorials for Pharo by enabling the creation and embedding of Epicea change sessions directly in the document. For example, take a look at the following animation: >> https://twitter.com/feenkcom/status/999975333972541440 >> >> The document shows a method on top, and a change preview at the bottom showing both the code and the associated diff to the state from the image. Applying the change updates both the change view (no more diff), and method preview. This speeds up significantly the process of going through a tutorial. Furthermore, given that now the document shows the diff to the current image, the reader can safely explore alternative scenario and come back to the tutorial at any time without losing the overview. >> >> The size of the preview can also be adjusted live: >> https://twitter.com/feenkcom/status/1001152789874167808 >> https://twitter.com/feenkcom/status/1001407762285375490 >> >> You can see a live tutorial by inspecting: >> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. >> >> >> Interactive data notebook: >> ---- >> A Documenter document can also be used as an interactive notebook. Internally it essentially acts as a playground: >> â¢ it supports defining variables in code snippets, and >> â¢ the execution of code shows an embedded inspector. >> >> For example: >> https://twitter.com/feenkcom/status/996310432225820672 >> https://twitter.com/feenkcom/status/1002851190475026432 >> >> An example, can be seen by inspecting: >> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'gtoolkit' / 'gtoolkit.pillar'. >> >> >> As always, please do let us know what you think. >> >> Enjoy, >> The feenk team >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you can't say why something is relevant, >> it probably isn't." >> > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

June 15, 2018

Re: [Pharo-users] [ann] gt documenter

by Offray Vladimir Luna CÃ¡rdenas

Cool! I hope to see how this could be integrated in Grafoscopio once Documenter is better integrated with Pharo, for example addressing the font issues already reported in the mailing list on Manjaro Linux (64 bits) and in the thread at [1] and also the Markdown integration possibilities (which are never answered). [1] https://twitter.com/feenkcom/status/996310432225820672 I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to use it in a more confident day to day fashion. Keep the interesting work. Cheers, Offray On 13/06/18 15:57, Tudor Girba wrote: > Hi, > > We are happy to announce a new leap of GToolkit Documenter, the tool > for manipulating live documents directly in the development environment: > https://github.com/feenkcom/gtoolkit-documenter > > Documenter is part of the second generation GToolkit project,Â it is > based onÂ BlocÂ and works with the latestÂ Pillar. It is mainly developed > by Juraj Kubelka. > > Attached you can see a preview of how documents look like: > > > > At its core it offers a live editor for manipulating Pillar documents. > The interactionÂ happens seamlessly directly in the text editor, and it > can be combined with differentÂ types of previews to serve several > classes of use cases: > â¢ codeÂ documentation > â¢ tutorials > â¢ interactive data notebook > > > Code documentation > ---- > Documenter complements theÂ GToolkit Examples engineÂ to redefine > codeÂ documentation. When practicing example-driven development, > examples getÂ written as part of the typical development. Once examples > exist, they can beÂ quickly put together in a document to form > documentation. For example, the linked picture shows the comment of a > class containing a visual explanation: > https://twitter.com/feenkcom/status/973899862482866176 > > You can see a live example of documentation by inspecting the > following snippet: > GtDocumenter editorForText: BrToggleExamples comment.Â > > > Tutorials: > ---- > Documenter offers a new experience of writing tutorials for Pharo by > enabling theÂ creation and embedding of Epicea change sessions directly > in the document. ForÂ example, take a look at the following animation: > https://twitter.com/feenkcom/status/999975333972541440 > > The document shows a method on top, and a change preview at the > bottomÂ showing both the code and the associated diff to the state from > the image.Â Applying the change updates both the change view (no more > diff), and methodÂ preview. This speeds up significantly the process of > going through a tutorial. Furthermore,Â given that now the document > shows the diff to the current image, the reader canÂ safely explore > alternative scenario and come back to the tutorial at any time > withoutÂ losing the overview. > > The size of the preview can also be adjusted live: > https://twitter.com/feenkcom/status/1001152789874167808 > https://twitter.com/feenkcom/status/1001407762285375490 > > You can see a live tutorial by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / > 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. > > > Interactive data notebook: > ---- > A Documenter document can also be used as an interactive notebook. > Internally itÂ essentially acts as a playground: > â¢ it supports defining variables in code snippets, and > â¢ the execution of code shows an embedded inspector. > > For example: > https://twitter.com/feenkcom/status/996310432225820672 > https://twitter.com/feenkcom/status/1002851190475026432 > > An example, can be seen by inspecting: > IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / > 'gtoolkit' / 'gtoolkit.pillar'.Â > > > As always, please do let us know what you think. > > Enjoy, > The feenk team > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "If you can't say why something is relevant,Â > it probably isn't." >

June 15, 2018

Re: [Pharo-users] How to contribute to Pharo Launcher?

by Cyril Ferlicot D.

Le 14/06/2018 Ã 21:04, Esteban Lorenzano a Ã©critÂ : > > > The main maintainer is Christophe, which I know feels a lot more confortable with git than with monticello. > So, I guess reason of not moving it is other :) > > Maybe is time for moving it? > If there is no other reason than "nobody did it", I can find some time to do it. The only problem is that I don't have the rights on the Jenkins. > Esteban > > -- Cyril Ferlicot https://ferlicot.fr

June 14, 2018

Re: [Pharo-users] How to contribute to Pharo Launcher?

by Esteban Lorenzano

> On 14 Jun 2018, at 20:56, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 14/06/2018 Ã 18:48, Tim Mackinnon a Ã©crit : > > Hi, > > >> Is PharoLauncher using git - there is a note saying the StHub repo is about to be moved? >> > > For now it is still on STHub. Maybe because the main maintainers are > more efficient with Monticello than with github? Maybe the main > maintainers did not had the time to move the project? The main maintainer is Christophe, which I know feels a lot more confortable with git than with monticello. So, I guess reason of not moving it is other :) > >> I ask as I wanted to contribute a simple change that shows the modified date of the images and lets you sort by that (I sometimes forget which was the latest image I was using and have a few old ones kicking around). >> > > Currently if you want to contribute you need to ask to be added to the > Pharo group on Smalltalkhub. Maybe is time for moving it? Esteban > >> Tim >> > > > -- > Cyril Ferlicot > https://ferlicot.fr >

June 14, 2018

Re: [Pharo-users] How to contribute to Pharo Launcher?

by Cyril Ferlicot D.

Le 14/06/2018 Ã 18:48, Tim Mackinnon a Ã©critÂ : Hi, > Is PharoLauncher using git - there is a note saying the StHub repo is about to be moved? > For now it is still on STHub. Maybe because the main maintainers are more efficient with Monticello than with github? Maybe the main maintainers did not had the time to move the project? > I ask as I wanted to contribute a simple change that shows the modified date of the images and lets you sort by that (I sometimes forget which was the latest image I was using and have a few old ones kicking around). > Currently if you want to contribute you need to ask to be added to the Pharo group on Smalltalkhub. > Tim > -- Cyril Ferlicot https://ferlicot.fr

June 14, 2018

How to contribute to Pharo Launcher?

by Tim Mackinnon

Is PharoLauncher using git - there is a note saying the StHub repo is about to be moved? I ask as I wanted to contribute a simple change that shows the modified date of the images and lets you sort by that (I sometimes forget which was the latest image I was using and have a few old ones kicking around). Tim

June 14, 2018

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

by Thierry Goubier

2018-06-14 15:39 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: > Yes - Iâm a fan of small checkins (not always great at it, but I strive > for it) - and yes, the issue Iâve had is the same as what Thierry mentions > - my Smalltalk code is tied to an external file which has some rewrite > rules that depend on the classes I have in my image. I could possibly > generate them from the Smalltalk code (this is something Sean does) - but I > can see all kinds of reasons to atomically checkin code together. > > And generating is not allways possible. > It havenât tried it - but Iâm guessing if I stick non smalltalk things in > my src directory, that might work (ugly and potentially confusing, but it > might do the trick). OR Iâve just learned about #addFilesToIndex: which > might help me in this case. > I wouldn't put things in the src directory. FileTree, for one, is implemented by "I erase everything on-disk, then I write back my package", which has a non-negligeable chance of erasing non-Smalltalk data in there. The addFilesToIndex: should work, but the question becomes what is the hook to automatically call it when saving your project with Iceberg. > > But as a more general (and easier to understand) solution - working well > in a polyglot arena and checking other stuff in would be very handy. Hence > my âstagingâ proposal (if it would work?). > Probably, yes. > > Alternatively, I will try and see what happens if I commit locally > (without push) and then use my external tool to commit other files and then > do the final push t(talking about it here helped me spot what could be an > easy workaround). Still, I do hope we can keep working on the tools to get > to something a bit more sophisticated - as the full atomic commit is the > obvious end goal. > Consider using git squash, then. And calling git squash could be automated. One run the risk of turning Iceberg in a complete language-agnostic git client, which could make it too big to be sustainable in the long term. Thierry > > Tim > > > On 14 Jun 2018, at 12:12, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > Hi Norbert, Tim, > > 2018-06-14 11:33 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >> >> >> 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? >> > > A single commit allow one to make sure that both the smalltalk code and > the external resource are well in sync, and that you may not ending up in a > situation were at commit j has data format v1 and smalltalk code for format > v2, because it is in commit j+1 that you rewrote the data in format v2. > > I had that issue recently with a Pharo / FPGA project with a Pharo package > generating state machines to be integrated in a Verilog FPGA design with C > code for the drivers, the softcore in the FPGA, and test programs, and both > Pharo and the C/FPGA working out of the same test data... And that whole > thing getting regularly out of sync. > > IMHO: I'd model a concept of "multi-lingual projet" for that sort of > things, where one can list, in Pharo, Monticello packages and external > files or directories. Whatever the technology you use (OSProcess, libgit, > whatever...) it is easy then to commit all this in a single pass. On a > per-package basis, I'd see the package manifest as a suitable place for > listing external resources. On a per-project basis, a possible place could > be the manifest for the BaselineOf the project. > > Thierry > > >> >> 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> >> 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

Yes - Iâm a fan of small checkins (not always great at it, but I strive for it) - and yes, the issue Iâve had is the same as what Thierry mentions - my Smalltalk code is tied to an external file which has some rewrite rules that depend on the classes I have in my image. I could possibly generate them from the Smalltalk code (this is something Sean does) - but I can see all kinds of reasons to atomically checkin code together. It havenât tried it - but Iâm guessing if I stick non smalltalk things in my src directory, that might work (ugly and potentially confusing, but it might do the trick). OR Iâve just learned about #addFilesToIndex: which might help me in this case. But as a more general (and easier to understand) solution - working well in a polyglot arena and checking other stuff in would be very handy. Hence my âstagingâ proposal (if it would work?). Alternatively, I will try and see what happens if I commit locally (without push) and then use my external tool to commit other files and then do the final push t(talking about it here helped me spot what could be an easy workaround). Still, I do hope we can keep working on the tools to get to something a bit more sophisticated - as the full atomic commit is the obvious end goal. Tim > On 14 Jun 2018, at 12:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Norbert, Tim, > > 2018-06-14 11:33 GMT+02:00 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: > > >> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon <tim(a)testit.works <mailto:tim@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? > > A single commit allow one to make sure that both the smalltalk code and the external resource are well in sync, and that you may not ending up in a situation were at commit j has data format v1 and smalltalk code for format v2, because it is in commit j+1 that you rewrote the data in format v2. > > I had that issue recently with a Pharo / FPGA project with a Pharo package generating state machines to be integrated in a Verilog FPGA design with C code for the drivers, the softcore in the FPGA, and test programs, and both Pharo and the C/FPGA working out of the same test data... And that whole thing getting regularly out of sync. > > IMHO: I'd model a concept of "multi-lingual projet" for that sort of things, where one can list, in Pharo, Monticello packages and external files or directories. Whatever the technology you use (OSProcess, libgit, whatever...) it is easy then to commit all this in a single pass. On a per-package basis, I'd see the package manifest as a suitable place for listing external resources. On a per-project basis, a possible place could be the manifest for the BaselineOf the project. > > Thierry > > > 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 Thierry Goubier

Hi Norbert, Tim, 2018-06-14 11:33 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > > 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? > A single commit allow one to make sure that both the smalltalk code and the external resource are well in sync, and that you may not ending up in a situation were at commit j has data format v1 and smalltalk code for format v2, because it is in commit j+1 that you rewrote the data in format v2. I had that issue recently with a Pharo / FPGA project with a Pharo package generating state machines to be integrated in a Verilog FPGA design with C code for the drivers, the softcore in the FPGA, and test programs, and both Pharo and the C/FPGA working out of the same test data... And that whole thing getting regularly out of sync. IMHO: I'd model a concept of "multi-lingual projet" for that sort of things, where one can list, in Pharo, Monticello packages and external files or directories. Whatever the technology you use (OSProcess, libgit, whatever...) it is easy then to commit all this in a single pass. On a per-package basis, I'd see the package manifest as a suitable place for listing external resources. On a per-project basis, a possible place could be the manifest for the BaselineOf the project. Thierry > > 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> > 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