Smalltalk › Gemtalk › GLASS

okay ... here we go ...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Dale Henrichs

okay ... here we go ...

I've just announced the Metacello Preview release[1] on the Metacello mailing list.

The preview has been tested in GemStone 2.4.x against GLASS 1.0-beta.8.7.2 and starting tomorrow I will make sure that it works against GemStone 3.1 (if you're on GemStone 3.0.1 and are interested let me know and I'll make sure that the preview works on 3.0.1).

If you're not on the Metacello mailing list I wanted to make sure that you guys are aware of the Preview release and to invite you to take a look at the Metacello Scripting API and give me feedback ... So please take a minute and read the announcement[1].

.... cue Jeopardy music ...

Besides the scripting api, the Preview release introduces git/github support and that is the real reason for this mail. In the mail to the Metacello mailing list, I played down git/github, because I think that the early work there needs to be done with a relatively small group of people and it's probably best that I participate in the development project to have first hand awareness of any issues that may crop up.

I'd like that "small group of people" to be the GLASS users. Paul DeBruicker and I have already done a bit of work on porting Zinc[3] to GemStone using FileTree and GitHub. We've also got the Zodiac project[4] (providing TLS/SSL support) queued up in the GlassDB project[2]

I realize that most of you are already very busy, but I think that most of you are looking forward to being able to use Zinc and Zodiac on your own projects and if you start using the Metacello Preview release you'll be able to load the projects into your systems ... at a minimum and that will be a big help in trying our the git/github support for the Metacello Preview.

Moving forward I will be dedicating time to the Zinc and Zodiac ports. If there are folks that have the time to participate in the porting effort, get a github account and I'll add you as a glassdb developer. If there are folks that are interested in using the Zinc and Zodiac ports, sit tight and watch this list for availability announcements.

If you are going to do development then you'll need to install git in your development environment and learn a bit about git and GitHub. I can provide references for documentation and give general guidelines - One of the goals of the preview process is to develop some materials for using git/github and Smalltalk - for the most part we will be making up the rules as we go along at this early stage ...

If you planning on being a consumer of the Zinc and Zodiac ports, then you won't even need to install git, the downloads are zipballs and the whole download process is handled behind the scenes by Metacello and the github repository.

So please let me know your level of interest and your availability.

As always, questions and comments are welcome.

Dale

[1] http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-tt4642064.html
[2] https://github.com/glassdb
[3] https://github.com/glassdb/zinc
[4] https://github.com/glassdb/zodiac

Ken Treis

Re: okay ... here we go ...

Hi Dale,

I'm late to the party, but I'll bite anyway. I'm super excited about the github-flow model. It looks really attractive and would solve some of the challenges we've had with our current development flow.

We've picked a project to try this on and are feeling our way through git (a couple of us have some minimal familiarity). A couple of us branched off of a master (the always-deployable trunk); one merged fine and the other is giving me problems because of conflicts in the Monticello version history.

# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: packages/Core.package/monticello.meta/version

How are you handling this sort of situation? Even though git can easily handle the code merges, Monticello wants to keep its own ancestry that seems, at least on the surface, to need to match the git ancestry. But I don't want to maintain it, and git doesn't know how to merge it. Maybe we should just tell git to ignore that part of the filetree repository?

It's a little annoying to have to enter commit details in both the image *and* on the command line when I commit in git, but I'm a generally patient guy so I'm doing OK with that for now.

--
Ken Treis
Miriam Technologies, Inc.

On Jul 29, 2012, at 10:22 AM, Dale Henrichs wrote:

I've just announced the Metacello Preview release[1] on the Metacello mailing list.

The preview has been tested in GemStone 2.4.x against GLASS 1.0-beta.8.7.2 and starting tomorrow I will make sure that it works against GemStone 3.1 (if you're on GemStone 3.0.1 and are interested let me know and I'll make sure that the preview works on 3.0.1).

If you're not on the Metacello mailing list I wanted to make sure that you guys are aware of the Preview release and to invite you to take a look at the Metacello Scripting API and give me feedback ... So please take a minute and read the announcement[1].

.... cue Jeopardy music ...

Besides the scripting api, the Preview release introduces git/github support and that is the real reason for this mail. In the mail to the Metacello mailing list, I played down git/github, because I think that the early work there needs to be done with a relatively small group of people and it's probably best that I participate in the development project to have first hand awareness of any issues that may crop up.

I'd like that "small group of people" to be the GLASS users. Paul DeBruicker and I have already done a bit of work on porting Zinc[3] to GemStone using FileTree and GitHub. We've also got the Zodiac project[4] (providing TLS/SSL support) queued up in the GlassDB project[2]

I realize that most of you are already very busy, but I think that most of you are looking forward to being able to use Zinc and Zodiac on your own projects and if you start using the Metacello Preview release you'll be able to load the projects into your systems ... at a minimum and that will be a big help in trying our the git/github support for the Metacello Preview.

Moving forward I will be dedicating time to the Zinc and Zodiac ports. If there are folks that have the time to participate in the porting effort, get a github account and I'll add you as a glassdb developer. If there are folks that are interested in using the Zinc and Zodiac ports, sit tight and watch this list for availability announcements.

If you are going to do development then you'll need to install git in your development environment and learn a bit about git and GitHub. I can provide references for documentation and give general guidelines - One of the goals of the preview process is to develop some materials for using git/github and Smalltalk - for the most part we will be making up the rules as we go along at this early stage ...

If you planning on being a consumer of the Zinc and Zodiac ports, then you won't even need to install git, the downloads are zipballs and the whole download process is handled behind the scenes by Metacello and the github repository.

So please let me know your level of interest and your availability.

As always, questions and comments are welcome.

Dale

[1] http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-tt4642064.html
[2] https://github.com/glassdb
[3] https://github.com/glassdb/zinc
[4] https://github.com/glassdb/zodiac

otto

Re: okay ... here we go ...

Hi,

> I'm late to the party, but I'll bite anyway. I'm super excited about the
> github-flow model. It looks really attractive and would solve some of the
> challenges we've had with our current development flow.

Yes, also doing that in a way. Very nice.

> # both modified: packages/Core.package/monticello.meta/version
>
> How are you handling this sort of situation? Even though git can easily
> handle the code merges, Monticello wants to keep its own ancestry that
> seems, at least on the surface, to need to match the git ancestry. But I
> don't want to maintain it, and git doesn't know how to merge it. Maybe we
> should just tell git to ignore that part of the filetree repository?

This has been a bit of a pain for us too, especially with a few
developers on the same packages.

We have found that it is important to bump the version number and to
change the uuid in the merged version. I usually choose my own version
file and increase the version number to one more than the biggest of
the ones I'm merging in (including the one I created). I also change
the last digit of the uuid to make sure that when I load it in my
image, monticello sees the package as different. We do this because we
have to load the package back into the image and we have found that if
we don't, all the changes are not necessarily loaded. If you don't,
and you make more changes to the package, we found that you overwrite
other peoples' changes because they were not loaded into the image.

We do not maintain or merge the ancestry; we generally just wipe it.

I would ideally not like to maintain the version file at all. I think
it can be generated using all the information in the git repository.
Or diverge from Monticello packages.

HTH
Otto

Ken Treis

Re: okay ... here we go ...

On Aug 29, 2012, at 12:04 AM, Otto Behrens wrote:

We do not maintain or merge the ancestry; we generally just wipe it.

I would ideally not like to maintain the version file at all. I think
it can be generated using all the information in the git repository.
Or diverge from Monticello packages.

Here's the solution we're trying. I don't know if it'll work, but so far it's been easier than resolving conflicts and bumping UUIDs.

The attached script (written in Ruby) generates the monticello.meta/version file from the git log. I've put the script in my repository in a top-level directory called "scripts", and then we:

1. git rm packages/*/monticello.meta/version

2. add packages/*/monticello.meta/version to .gitignore

3. set up a post-checkout hook to run it:

#!/usr/bin/bash

for i in packages/*; do scripts/git2mc $i; done

Potential issues/caveats with this script:

* The reconstructed ancestry is purely linear. It should be possible to reconstruct a more accurate ancestry, but I don't need it. I just go in the order things come out of git log.

* I rewrite version numbers from 1..n, where n is the total number of commits in the git log for that package's directory. I'm not sure if this will cause any problems in Squeak/Pharo. For the way we're planning on implementing github-flow for our GemStone deployments, we don't anticipate any problems since the master branch will always be growing. There may also be issues with the Monticello package cache.

* For UUIDs, I hack up something UUID-ish from the SHA of the git commit. That means that if you merge earlier commits, the UUID won't change (even though the version number will). Again, not sure if this will cause any problems in Squeak/Pharo but so far it's fine for us.

* I'm a Smalltalker and this is a tiny throw-away script. Don't look at this for an example of good Ruby coding.

So far, we like the way this is working. We don't even bother filling in Monticello comments, since they get clobbered anyway. And with

Comments? Thoughts?

--
Ken Treis
Miriam Technologies, Inc.

git2mc (2K) Download Attachment

Dale Henrichs

Re: okay ... here we go ...

In reply to this post by Ken Treis

Ken and Otto ... understood ...

The current scheme of storing Monticello meta data is a compromise so that folks don't have to go "all in" when moving to filetree, ideally git will be used to supply the details of (method author/timestamp/comment/ancestry).

I encourage creativity when it comes to making solutions that work better in your own environments ... the beauty of the FileTree/Cypress approach is that there's quite a bit of flexibility in what meta information is needed ...

Dale

----- Original Message -----
| From: "Ken Treis" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Tuesday, August 28, 2012 4:48:41 PM
| Subject: Re: [GS/SS Beta] okay ... here we go ...
|
| Hi Dale,
|
|
| I'm late to the party, but I'll bite anyway. I'm super excited about
| the github-flow model. It looks really attractive and would solve
| some of the challenges we've had with our current development flow.
|
|
| We've picked a project to try this on and are feeling our way through
| git (a couple of us have some minimal familiarity). A couple of us
| branched off of a master (the always-deployable trunk); one merged
| fine and the other is giving me problems because of conflicts in the
| Monticello version history.
|
|
|
|
|
|
|
|
|
| # Unmerged paths:
| # (use "git reset HEAD <file>..." to unstage)
| # (use "git add/rm <file>..." as appropriate to mark resolution)
| #
| # both modified: packages/Core.package/monticello.meta/version
|
|
|
| How are you handling this sort of situation? Even though git can
| easily handle the code merges, Monticello wants to keep its own
| ancestry that seems, at least on the surface, to need to match the
| git ancestry. But I don't want to maintain it, and git doesn't know
| how to merge it. Maybe we should just tell git to ignore that part
| of the filetree repository?
|
|
| It's a little annoying to have to enter commit details in both the
| image *and* on the command line when I commit in git, but I'm a
| generally patient guy so I'm doing OK with that for now.
|
|
|
|
|
|
|
|
|
| --
| Ken Treis
| Miriam Technologies, Inc.
|
|
| On Jul 29, 2012, at 10:22 AM, Dale Henrichs wrote:
|
|
|
| I've just announced the Metacello Preview release[1] on the Metacello
| mailing list.
|
| The preview has been tested in GemStone 2.4.x against GLASS
| 1.0-beta.8.7.2 and starting tomorrow I will make sure that it works
| against GemStone 3.1 (if you're on GemStone 3.0.1 and are interested
| let me know and I'll make sure that the preview works on 3.0.1).
|
| If you're not on the Metacello mailing list I wanted to make sure
| that you guys are aware of the Preview release and to invite you to
| take a look at the Metacello Scripting API and give me feedback ...
| So please take a minute and read the announcement[1].
|
| .... cue Jeopardy music ...
|
| Besides the scripting api, the Preview release introduces git/github
| support and that is the real reason for this mail. In the mail to
| the Metacello mailing list, I played down git/github, because I
| think that the early work there needs to be done with a relatively
| small group of people and it's probably best that I participate in
| the development project to have first hand awareness of any issues
| that may crop up.
|
| I'd like that "small group of people" to be the GLASS users. Paul
| DeBruicker and I have already done a bit of work on porting Zinc[3]
| to GemStone using FileTree and GitHub. We've also got the Zodiac
| project[4] (providing TLS/SSL support) queued up in the GlassDB
| project[2]
|
| I realize that most of you are already very busy, but I think that
| most of you are looking forward to being able to use Zinc and Zodiac
| on your own projects and if you start using the Metacello Preview
| release you'll be able to load the projects into your systems ... at
| a minimum and that will be a big help in trying our the git/github
| support for the Metacello Preview.
|
| Moving forward I will be dedicating time to the Zinc and Zodiac
| ports. If there are folks that have the time to participate in the
| porting effort, get a github account and I'll add you as a glassdb
| developer. If there are folks that are interested in using the Zinc
| and Zodiac ports, sit tight and watch this list for availability
| announcements.
|
| If you are going to do development then you'll need to install git in
| your development environment and learn a bit about git and GitHub. I
| can provide references for documentation and give general guidelines
| - One of the goals of the preview process is to develop some
| materials for using git/github and Smalltalk - for the most part we
| will be making up the rules as we go along at this early stage ...
|
| If you planning on being a consumer of the Zinc and Zodiac ports,
| then you won't even need to install git, the downloads are zipballs
| and the whole download process is handled behind the scenes by
| Metacello and the github repository.
|
| So please let me know your level of interest and your availability.
|
| As always, questions and comments are welcome.
|
| Dale
|
| [1]
| http://forum.world.st/Metacello-Preview-release-1-0-beta-32-2-tt4642064.html
| [2] https://github.com/glassdb
| [3] https://github.com/glassdb/zinc
| [4] https://github.com/glassdb/zodiac
|
|