Baseline depending on a baseline

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

On 09/08/2015 08:12 AM, Sean DeNigris wrote:
> In BaselineOfMyProject>>baseline:, I have:
>     spec baseline: ‘Dependent Project' with: [
>         spec repository:
> 'github://seandenigris/DependentProject:master/repository' ].
>
> IIUC, using github:// will give me a read-only copy, right? Is it
> frozen, or can it be updated to the latest code from GitHub?
it can be updated to the latest version ... the trigger for this is to do:

    Metacello image
      baseline: 'DependentProject';
      get.

When you `get` a baseline, the github download is refreshed during the
next load ...
>
> Assuming that it’s read-only, my next move would be to make it
> gitfiletree://. Is that supported? Does GitFileTree have to be loaded
> already?
I think that you can use a `gitfiletree://` description in a repository
spec ... I haven't done it myself, but I think that Thierry has been
able to arrange for that to work ... I would be willing to add it to
Metacello if it didn't work ...

If it does work, then I would suggest that you consider using github://
in your public Baseline (portable to GemStone and Squeak) and use a
`lock` for your local development. Doing something like this:

   Metacello new
     baseline: 'DependentProject';
     repository: 'gitfiletree://.....';
     lock.

This means that gitfiletree: will be used in this image only, for all
references to DependentProject... Other users will use github://  ...
>
> As a backstop, I could use filetree:// if that’s supported. I feel
> like I’ve seen that used but my head is spinning a bit right now
> learning to use Git in Smalltalk!

If gitfiletree:// works then you can put off learning git a bit longer:) ...

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dale Henrichs-3 wrote

it can be updated to the latest version ...

Ah, good to know! But I was asking because I wanted to commit changes to it, not update.

Dale Henrichs-3 wrote

Does GitFileTree have to be loaded
> already?
I think that you can use a `gitfiletree://` description in a repository
spec ... I would be willing to add it to
Metacello if it didn't work ...

So it sounds like GitFileTree would have to be loaded, which is not too bad because my use case is a private project which only developers need to load via MetaC.

Dale Henrichs-3 wrote

use a `lock` for your local development... repository: 'gitfiletree://.....'; lock.

Ah, another good trick :)

I think for my current use case, filetree:// will actually make the most sense because the git repos in question will be already cloned on the development machines, and that will eliminate the extra step of installing GitFileTree, although it would be sweet if MetaC supported gitfiletree:// directly!

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.

Dale Henrichs-3 wrote
it can be updated to the latest version ...

Ah, good to know! But I was asking because I wanted to commit changes to it,
not update.

Oh ... then you need to learn git:)

Dale Henrichs-3 wrote
Does GitFileTree have to be loaded
already?
I think that you can use a `gitfiletree://` description in a repository
spec ... I would be willing to add it to
Metacello if it didn't work ...

So it sounds like GitFileTree would have to be loaded, which is not too bad
because my use case is a private project which only developers need to load
via MetaC.

... or use GitFileTree:)

Dale Henrichs-3 wrote
use a `lock` for your local development... repository:
'gitfiletree://.....'; lock.

Ah, another good trick :)

Yeah `lock` was invented so that you could manage your local git repos without having to change all of the github:// references in the external configurations and baselines...

I think for my current use case, filetree:// will actually make the most
sense because the git repos in question will be already cloned on the
development machines, and that will eliminate the extra step of installing
GitFileTree, although it would be sweet if MetaC supported gitfiletree://
directly!

Technically gitfiletree:// is part of the FileTree project (for Pharo only), so it you wanted to avoid the extra step of installing, that is an issue to take up with the Pharo folks?

gitfiletree:// is not so much a disk format as a Pharo-based tool set ... the bits on disk are filetree:// but the code that loads/save/manages the bits on disk has a richer toolset in-image....

From the Metacello perspective gitfiletree:// is fully supported on Pharo:) ... I think.

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.