[Glass] Git based repositories (package-cache) problem when moving extent to another stone

[Dale Henrichs via Glass]

On 10/26/2015 03:03 PM, Mariano Martinez Peck via Glass wrote:
> Dale,
>
> I am finding problems with git-based repositories. Basically, let's 
> say I load some stuff from git under the stone called 3.2.9. Then I 
> copy the extent and I restore such a extent in another stone, called 
> 'otherStone'.
What scripts steps do you use when you"copy and restore in another 
stone" ....
>
> I now try to update code in my 'otherStone' and I get an exception 
> while loading Seaside from metacello. The problem ends up being that 
> in fact it is trying to get the stuff from here:
>
> '/opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'
Ah okay ... I've been working with local clones of all of the projects 
(the mode that I think everyone should follow) ... the problem you are 
seeing has to do with using github:// repositories ... git repositories 
use filetree:// and the expectation is that you are moving extents 
within the same $GS_HOME environment ... nonetheless this should work ...
>
> All those files have a different OS owner and file permissiones etc etc.
>
> Of course, if I remove 
> /opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache 
>   it suddenly starts to work in 'otherStone'.
This seems to be a bug in MCGitHubRepository ... specifically 
MCGitHubRepository class>>resetCacheDirectoryIfInvalid will reset the 
CacheDirectory if it's no longer "valid" but it's test for "valid" is 
that the directory exists ... it should also worry about permissions ... 
I guess ... alternatively I could catch an error on access and reset the 
CacheDirectory and try again ... I don't know if there is platform 
independent protocol in Metacello for doing permission testing ... no 
quick fix there, I think ....

In the mean time, you can clear the cache directory manually:

   MCGitHubRepository cacheDirectory: nil.

If you are using $GS_HOME/bin/newExtent or $GS_HOME/bin/createStone with 
the `-t` option (which you should be), then newExtent ends up running 
the `rebuildServerTode` script:

   $GS_HOME/bin/todeIt $stoneName "script --script=rebuildServerTode"

which itself runs $GS_HOME/sys/local/client/tode-scripts/rebuildSys ... 
whose job is to do things like make sure that the freshly copied extent 
is adapted correctly to it's new environment so I think that adding this 
line to the script would be correct:

   eval `MCGitHubRepository cacheDirectory: nil`

In fact, if you don't get there first, I'll submit a Metacello bug 
report, and then add this patch (along with a reference to the Metacello 
bug) to rebuildSys. I'm not planning a drop for a day or so, so if you 
want me to do the patch sooner, I can slipstream the patch  into master 
and then create the bug and comment the patch with my next regular Early 
Access drop ...

I might be inclined to think that patch actually belongs there ... when 
you move an extent ... all of the disk caches should be cleared ....

Dale