> 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 <esteba...@gmail.com> wrote: > > > >> 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 >>> >>> >> >> > >
