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

Guillermo Polito guillermopolito at gmail.com
Thu Jun 14 05:04:25 EDT 2018


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 at 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 at 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 at 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 at 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 at 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 at 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 at gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim at 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 at gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> hi,
>>>> >>>
>>>> >>>
>>>> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20180614/ebb792b9/attachment-0001.html>


More information about the Pharo-users mailing list