> On 13 Jun 2018, at 22:44, Tim Mackinnon <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 <esteba...@gmail.com> wrote:
>>
>> hi,
>>
>>
>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <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
>>
>>
>
>
