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

[Mariano Martinez Peck via Glass]

On Mon, Oct 26, 2015 at 7:58 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

>
>
> 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 do a snapshot with tODE then a cp of the extent.


>
>
>> 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 ...


Yes, the problem I found is when using github repos, not filetree (at least
the error I had), and yes, using same $GS_HOME.


>
>
>> 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 ....
>

Yes, that's exactly the point. In my case, the 'another' stone runs with a
different OS user and hence there is a permission issue at file system
level.



>
> 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`
>
>
Thanks. I just tried it but it seems it is not yet enough. Look at the
exception I get:

Inspect
MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
@31 line 39a GoferRepositoryError occurred (error 2710), a
ImproperOperation occurred (error 2085), Expected nil to be a Boolean./
--------------------
.              -> a GoferRepositoryError occurred (error 2710), a
ImproperOperation occurred (error 2085), Expected nil to be a Boolean.
..             -> aMetacelloEnsureFetchingMCSpecLoader(explicit load : 1.6
[ConfigurationOfIAM])
(class)@       -> GoferRepositoryError
(oop)@         -> 1767077889
currGsHandler@ -> nil
gsArgs@        -> nil
gsDetails@     -> 'a ImproperOperation occurred (error 2085), Expected nil
to be a Boolean.'
gsNumber@      -> 2710
gsReason@      -> nil
gsResumable@   -> false
gsStack@       -> nil
gsTrappable@   -> true
messageText@   -> 'a GoferRepositoryError occurred (error 2710), a
ImproperOperation occurred (error 2085), Expected nil to be a Boolean.'
repository@    ->
aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)
tag@           -> nil


And when I inspect the 'repository' I get this:

Inspect
MetacelloEnsureFetchingMCSpecLoader(MetacelloCommonMCSpecLoader)>>retryingResolvePackageSpecReferences:gofer:
@31 line 39a GoferRepositoryError occurred (error 2710), a
ImproperOperation occurred (error 2085), Expected nil to be a
Boolean./aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)/
--------------------
.                      ->
aMCGitHubRepository(github://GsDevKit/Seaside31:v3.1.4.2-gs/repository)
..                     -> a GoferRepositoryError occurred (error 2710), a
ImproperOperation occurred (error 2085), Expected nil to be a Boolean.
(class)@               -> MCGitHubRepository
(oop)@                 -> 1226322689
(committed)@           -> true
cache@                 -> nil
creationTemplate@      -> nil
directory@             -> aServerFileDirectory
projectPath@           -> 'GsDevKit/Seaside31'
projectVersion@        -> 'v3.1.4.2-gs'
projectVersionPattern@ -> '3.1.?'
readonly@              -> true
repoPath@              -> 'repository'
repositoryProperties@  -> aDictionary( 'packageExtension'->'.package',
'propertyFileExtension'->'.json')
storeDiffs@            -> nil


And as you can see the problematic is that 'directory' instVar.  if I send
#pathName to it, I get:

'/opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'

I tried sending #flushCache to the repository instance, but not luck..the
'directory' instVar still there...

Note that #flushCache of github class DOES nil the 'directory' instVar.
However, this is funny:

MCGitHubRepository cacheDirectory: nil.
MCRepositoryGroup default repositoriesDo: [:rep | rep flushCache ].
MCRepositoryGroup default repositoriesDo: [:each | (each projectVersion =
'v3.1.4.1-gs') ifTrue: [Halt halt] ].

And then it halts... 'each' continues to have again the wrong value in
'directory'. Shouldn't this be nil?    Of course I made sure the
#flushCache was really sent to the repository.

I don't get it.



> 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
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151026/41952028/attachment-0001.html>