Smalltalk › Frameworks & Tools › Monticello, Metacello ... › Metacello

Platform branches and loading via Filetree

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Sean DeNigris

Platform branches and loading via Filetree

I have my personal preferences in a DeNigrisPreferences project, which I load

via startup script from a local Filetree repository. I can do this because I

am currently managing platform differences via Metacello and platform

packages. Am I correct that "The Git Way" would be to have a branch per

platform? Am I further correct that if I go that route, I would have to

maintain a local checkout for each branch and choose in my script based on

detecting the underlying platform? I feel like I am missing something...

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

Re: Platform branches and loading via Filetree

On 3/5/16 3:04 PM, Sean DeNigris wrote:

>
> I have my personal preferences in a DeNigrisPreferences project, which
> I load
>
> via startup script from a local Filetree repository. I can do this
> because I
>
> am currently managing platform differences via Metacello and platform
>
> packages. Am I correct that "The Git Way" would be to have a branch per
>
> platform? Am I further correct that if I go that route, I would have to
>
> maintain a local checkout for each branch and choose in my script based on
>
> detecting the underlying platform? I feel like I am missing something..
>

A branch per platform, is something that I proposed pretty early on in
my work with git ... and I used that approach with the filetree project
on Girhub.

Nowadays, I am not as keen on that approach. Besides the inconvenience
of keeping multiple clones to service multiple platforms, it is not that
easy to share the common code between all of the branches as you have to
make liberal use of cherry-picking which is not quite as convenient as
doing branch merges ...

In practice it is much more convenient to simply maintain
platform-specific packages ...

The branch per platform approach is still useful if you need to fork a
project to port to a new platform. The STON and Zinc projects are
examples of this ... the STON and Zinc projects are only being
maintained for Pharo in the primary github repository, so when I ported
Zinc and STON to GemStone, I preserved the master branch as the pharo
branch and create a gs_master branch for GemStone and this works very
well ... but this turns out to be a case where you have to have separate
clones for the separate platforms anyway.

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.

Sean DeNigris

Re: Platform branches and loading via Filetree

I'm glad I asked before converting my project! I've gotten used to platform packages - not so bad…

On Sunday, March 6, 2016 at 12:15:45 AM UTC-5, Dale wrote:

On 3/5/16 3:04 PM, Sean DeNigris wrote:

>
> I have my personal preferences in a DeNigrisPreferences project, which
> I load
>
> via startup script from a local Filetree repository. I can do this
> because I
>
> am currently managing platform differences via Metacello and platform
>
> packages. Am I correct that "The Git Way" would be to have a branch per
>
> platform? Am I further correct that if I go that route, I would have to
>
> maintain a local checkout for each branch and choose in my script based on
>
> detecting the underlying platform? I feel like I am missing something..
>

A branch per platform, is something that I proposed pretty early on in
my work with git ... and I used that approach with the filetree project
on Girhub.

Nowadays, I am not as keen on that approach. Besides the inconvenience
of keeping multiple clones to service multiple platforms, it is not that
easy to share the common code between all of the branches as you have to
make liberal use of cherry-picking which is not quite as convenient as
doing branch merges ...

In practice it is much more convenient to simply maintain
platform-specific packages ...

The branch per platform approach is still useful if you need to fork a
project to port to a new platform. The STON and Zinc projects are
examples of this ... the STON and Zinc projects are only being
maintained for Pharo in the primary github repository, so when I ported
Zinc and STON to GemStone, I preserved the master branch as the pharo
branch and create a gs_master branch for GemStone and this works very
well ... but this turns out to be a case where you have to have separate
clones for the separate platforms anyway.

Dale

Sean DeNigris

Re: Platform branches and loading via Filetree

In reply to this post by Dale Henrichs-3

A branch per platform, is something that I proposed pretty early on…

Do you still recommend at 'configuration' branch?

Also, a small detail, but the docs recommend a 'packages' sub-folder, but recently I noticed you were using 'repository' instead. Why the change?

Dale Henrichs-3

Re: Platform branches and loading via Filetree

On 03/06/2016 12:25 PM, Sean DeNigris wrote:

A branch per platform, is something that I proposed pretty early on…

Do you still recommend at 'configuration' branch?

without multiple platform branches a "common" configuration branch is not needed either ...

In general I think that once you've move to github that you should just use a BaselineOf and do away with the configuration ...

The only real reason for using a ConfugrationOf is if you have to maintain compatibility with Monticello repos (mcz files).

Barring that, you should start using BaselineOf and then use git tags for identifying milestone versions and use tag wildcard patterns[1] in your project references. The following pattern is equivalent to definining a #'release2.4.3' symbolic version:

        spec baseline: 'ZincHTTPComponents'
          with: [
              spec
                repository: 'github://GsDevKit/zinc:2.4.3.?/repository';
                loads: #('Zinc-HTTP' 'SSL') ];
        yourself.

[1] https://github.com/dalehenrich/metacello-work/issues/277#issuecomment-58970696

Also, a small detail, but the docs recommend a 'packages' sub-folder, but recently I noticed you were using 'repository' instead. Why the change?

I don't know for certain whether it is still the case, but at a point in time I discovered that the contents of directories named `packages` were being ignored by the language recognition code, because a particular Windows project had an ignore directory for the `package` directory .. the implication was that if you put all all of your .st files into a directory named `packages`, github wouldn't recognize your project as a smalltalk project ...

At that point I converted to using `repository` instead of `packages` ... It's been quite awhile and if it is no longer true, then I would still recommend using `packages` as the directory name ...

If github is still ignoring files in a `packages` directory, then I's like to know and the docs should be changed ...

Dale

Sean DeNigris

Re: Platform branches and loading via Filetree

The only real reason for using a ConfugrationOf is if you have to maintain compatibility with Monticello repos (mcz files).

My only interest in a Config is to make it loadable from Pharo's Configuration Browser or Catalog…