branch per platform volunteers?

After my post on branch per platform, I realize that its not fair to ask for opinions based on a description ... the fair thing is to ask about opinions based on experience ...

So...are there any folks who have some spare time to devote to doing some branch per platform experiments?

Personally, I'm going to take metacello and convert it to branch per platform, but I'm willing to work with anyone else that wants to take a project for a spin ... it isn't necessary that the project be your own:

  - omnibrowser and shout might be good candidates for the experiment or maybe helpbrowser or grease?

we just need a relatively small multi-platform project to:

  1. create a git/github repo (we can use one of *verse
     organizations that I've created for my other experiments)
  2. convert to filetree using the steps outlined in previous
     post
  3. do some development on one platform and merge your changes to
     the other platforms


I'm trying to find out how practical this model is ... my take so far is that it is practical but requires a little getting used to as you have to use `git cherry-pick` which is just a bit off the beaten track, so I'm looking for a sanity check ...

I realize that folks are busy, but lacking any feedback I will continue moving forward and follow my gut:)

Dale

Hi Dale,

We develop in Pharo and deploy to GS, so it may make sense in our
case. We have some code that we only load into Pharo and some only in
GS (very small package).

So, we could be candidates. But I do think it is impractical to merge
branches all the time because we generally only have one branch; we
don't use feature branching.

It could work if we split out the platform specific code into a
separate git repo, with platform specific branches there. Don't think
it's worth the effort because we spend very little time there. I'll
have a look anyway.

Cheers
Otto

On 11 Apr 2012, at 18:27, Dale Henrichs <[hidden email]> wrote:

On 11 April 2012 17:26, Dale Henrichs <[hidden email]> wrote:
> After my post on branch per platform, I realize that its not fair to ask for opinions based on a description ... the fair thing is to ask about opinions based on experience ...
>
> So...are there any folks who have some spare time to devote to doing some branch per platform experiments?

I have a _bit_ of cross-platform experience - my Ruby zipper
implementation [1] supports Ruby 1.9.3, 1.9.2 and Ruby 1.8.7, and I
keep the two platform on, respectively, master, zipr-1.9.3 and
zipr-1.8.7. (Ruby's syntax underwent a few changes between 1.8.x and
1.9.x forcing me to support both, otherwise I wouldn't have bothered).

So far it's been rather annoying! Leaving aside the noise of the
syntactic changes (which are not entirely applicable to us, but think
of gst), this is more or less how I work:
* make a feature branch off whichever branch I happen to be on: if I
find a bug in branch foo, I'll branch off there, otherwise generally
it'll be off master.
* implement the feature/fix the bug
* commit
* for each platform branch,
** checkout the branch
** merge in the change somehow - you could squash a commit and
cherrypick, or pretend-merge and play with the staging and working dir
to remove the merge metadata
** commit

[1] https://github.com/frankshearar/zipr

cherry-pick is indeed a bit out there. It's also limited to picking a
single commit, so you might have to do even more out there stuff like
squashing to get that commit. Handily though, if you don't mind losing
the branching history, you can always merge --no-commit --noff your
feature branch, and fiddle with the staged changes to eliminate the
undesired changes (if any) and just commit as per normal.

One thing that will ease pain is doing what we have to already do:
keep the core stuff in one package, and platform-specific stuff in
separate packages. That will keep the platform specific stuff in
easily segregated directories/files (he says not thinking about
extensions).

frank

> I realize that folks are busy, but lacking any feedback I will continue moving forward and follow my gut:)
>
> Dale

Otto,

I'm trying to simplify the Metacello specification at the cost of using platform-specific branches and perhaps living with a more complex Metacello is less of an issue and I'd like to look at some of the pros and cons of doing so ..

Since you've lived with github for awhile you might not have to physically perform the experiment. Your perspective and opinions can be based on your experiences so far..

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, April 11, 2012 10:28:51 PM
| Subject: Re: [Metacello] branch per platform volunteers?
|
| Hi Dale,
|
| We develop in Pharo and deploy to GS, so it may make sense in our
| case. We have some code that we only load into Pharo and some only in
| GS (very small package).
|
| So, we could be candidates. But I do think it is impractical to merge
| branches all the time because we generally only have one branch; we
| don't use feature branching.
|
| It could work if we split out the platform specific code into a
| separate git repo, with platform specific branches there. Don't think
| it's worth the effort because we spend very little time there. I'll
| have a look anyway.
|
| Cheers
| Otto
|
| On 11 Apr 2012, at 18:27, Dale Henrichs <[hidden email]> wrote:
|
| > After my post on branch per platform, I realize that its not fair
| > to ask for opinions based on a description ... the fair thing is
| > to ask about opinions based on experience ...
| >
| > So...are there any folks who have some spare time to devote to
| > doing some branch per platform experiments?
| >
| > Personally, I'm going to take metacello and convert it to branch
| > per platform, but I'm willing to work with anyone else that wants
| > to take a project for a spin ... it isn't necessary that the
| > project be your own:
| >
| >  - omnibrowser and shout might be good candidates for the
| >  experiment or maybe helpbrowser or grease?
| >
| > we just need a relatively small multi-platform project to:
| >
| >  1. create a git/github repo (we can use one of *verse
| >     organizations that I've created for my other experiments)
| >  2. convert to filetree using the steps outlined in previous
| >     post
| >  3. do some development on one platform and merge your changes to
| >     the other platforms
| >
| >
| > I'm trying to find out how practical this model is ... my take so
| > far is that it is practical but requires a little getting used to
| > as you have to use `git cherry-pick` which is just a bit off the
| > beaten track, so I'm looking for a sanity check ...
| >
| > I realize that folks are busy, but lacking any feedback I will
| > continue moving forward and follow my gut:)
| >
| > Dale
|

One of the use cases that I am very familiar with is porting each new version of Seaside from pharo to gemstone so here are my thoughts from that perspective:

Seaside uses pharo-specific packages and gemstone has parallel gemstone-specific packages, but every time I port I find myself sweating the details of the changes that were made in the pharo-specific packages, because they might signal a required change in behavior that is related to changes made in the common packages ... I have to look at the details of each and every change that was made and try to decide whether to ignore it or not ...

I have also branched the 'common seaside packages'. So I end up having to look closely at which of the packages changed and do merges on each of the packages individually and hope that I don't trip over dependency issues.

In the common case the pharo-specific changes don't impact GemStone and the merges complete without dependency issues ... but it is tedious ...

In the branch per platform world, _IF_ (and it is a big if) the developers doing the development in pharo had cherry-picked the commits that involved common code, then my job in porting those changes to gemstone would be much simpler as I would only have to worry about merging the changes from the "common code branch" and not worry about the rest ...

If "topic branches" were used for resolving each issue, it would still be possible for a porting developer to come along, evaluate the "topic branch" and cherry-pick the branch if it involved common code before doing the merge ... this would still be an advantage, especially since the porters for other platforms could leverage this work and it would be a net win

If we don't use a "branch per platform", then developers are forced to use Monticello merges if they have done a branch of one of the common packages and they will have to copy and paste changes if they want to pick up changes from one of the other platform-specific packages ...

In the "branch per platform" I can use git level merges to pick up common changes and git level cherry-picks to grab non-common code from other branches and this makes life much easier ...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, April 11, 2012 9:26:55 AM
| Subject: [Metacello] branch per platform volunteers?
|
| After my post on branch per platform, I realize that its not fair to
| ask for opinions based on a description ... the fair thing is to ask
| about opinions based on experience ...
|
| So...are there any folks who have some spare time to devote to doing
| some branch per platform experiments?
|
| Personally, I'm going to take metacello and convert it to branch per
| platform, but I'm willing to work with anyone else that wants to
| take a project for a spin ... it isn't necessary that the project be
| your own:
|
|   - omnibrowser and shout might be good candidates for the experiment
|   or maybe helpbrowser or grease?
|
| we just need a relatively small multi-platform project to:
|
|   1. create a git/github repo (we can use one of *verse
|      organizations that I've created for my other experiments)
|   2. convert to filetree using the steps outlined in previous
|      post
|   3. do some development on one platform and merge your changes to
|      the other platforms
|
|
| I'm trying to find out how practical this model is ... my take so far
| is that it is practical but requires a little getting used to as you
| have to use `git cherry-pick` which is just a bit off the beaten
| track, so I'm looking for a sanity check ...
|
| I realize that folks are busy, but lacking any feedback I will
| continue moving forward and follow my gut:)
|
| Dale
|

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, April 12, 2012 2:31:44 AM
| Subject: Re: [Metacello] branch per platform volunteers?
|
| On 11 April 2012 17:26, Dale Henrichs <[hidden email]> wrote:
| > After my post on branch per platform, I realize that its not fair
| > to ask for opinions based on a description ... the fair thing is
| > to ask about opinions based on experience ...
| >
| > So...are there any folks who have some spare time to devote to
| > doing some branch per platform experiments?
|
| I have a _bit_ of cross-platform experience - my Ruby zipper
| implementation [1] supports Ruby 1.9.3, 1.9.2 and Ruby 1.8.7, and I
| keep the two platform on, respectively, master, zipr-1.9.3 and
| zipr-1.8.7. (Ruby's syntax underwent a few changes between 1.8.x and
| 1.9.x forcing me to support both, otherwise I wouldn't have
| bothered).
|
| So far it's been rather annoying! Leaving aside the noise of the
| syntactic changes (which are not entirely applicable to us, but think
| of gst), this is more or less how I work:
| * make a feature branch off whichever branch I happen to be on: if I
| find a bug in branch foo, I'll branch off there, otherwise generally
| it'll be off master.
| * implement the feature/fix the bug
| * commit
| * for each platform branch,
| ** checkout the branch
| ** merge in the change somehow - you could squash a commit and
| cherrypick, or pretend-merge and play with the staging and working
| dir
| to remove the merge metadata
| ** commit

Yep this sounds like the basic sequence of required operations ...

As I try to describe in my seaside post on this topic, I'm not sure that doing this type of work with Monticello is really any easier and the conclusion that I've come to is that git merge and cherry-pick are still better tools to use when doing this type of work ...

But I'd be interested to give us your perspective on how you'd think this would work with Monticello packages today and if a hybrid approach makes more sense than a branch per platform?

|
| [1] https://github.com/frankshearar/zipr
|
| > Personally, I'm going to take metacello and convert it to branch
| > per platform, but I'm willing to work with anyone else that wants
| > to take a project for a spin ... it isn't necessary that the
| > project be your own:
| >
| >  - omnibrowser and shout might be good candidates for the
| >  experiment or maybe helpbrowser or grease?
| >
| > we just need a relatively small multi-platform project to:
| >
| >  1. create a git/github repo (we can use one of *verse
| >     organizations that I've created for my other experiments)
| >  2. convert to filetree using the steps outlined in previous
| >     post
| >  3. do some development on one platform and merge your changes to
| >     the other platforms
| >
| >
| > I'm trying to find out how practical this model is ... my take so
| > far is that it is practical but requires a little getting used to
| > as you have to use `git cherry-pick` which is just a bit off the
| > beaten track, so I'm looking for a sanity check ...
|
| cherry-pick is indeed a bit out there. It's also limited to picking a
| single commit, so you might have to do even more out there stuff like
| squashing to get that commit. Handily though, if you don't mind
| losing
| the branching history, you can always merge --no-commit --noff your
| feature branch, and fiddle with the staged changes to eliminate the
| undesired changes (if any) and just commit as per normal.

I'm trying to train myself to create a topic branch at the first whiff of work. When you use a topic branch the merge back into your main (platform) branch is the commit that can be cherry-picked and is much preferable to having to cherry-pick each commit (I've done it both ways as well:).

|
| One thing that will ease pain is doing what we have to already do:
| keep the core stuff in one package, and platform-specific stuff in
| separate packages. That will keep the platform specific stuff in
| easily segregated directories/files (he says not thinking about
| extensions).

This is one of the areas that I have questions about ... on the one hand the packages do clearly demarcate the lines between common code and platform-specific code ... but it is a real pain to create and maintain these separate packages ... over time you trip across more and more platform dependencies (like using Author instead of Utilities) where you have to create more slots for indirection in your platform specific things whereas it is much simpler for everyone involved to use Author on the pharo branch and Utilities on the squeak branch.

If you look at the odd initialization structure that is employed for things like Seaside-Core and Seaside-Pharo-Core. You'll see what I mean ... Don't get me wrong in the mcz world these types of monkey business are necessary, but would not be necessary if we had a branch per platform ..

Dale

|
| frank
|
| > I realize that folks are busy, but lacking any feedback I will
| > continue moving forward and follow my gut:)
| >
| > Dale
|