[Glass] loading glass questions

Hi,

I'm loading GLASS (cloned from github.com/glassdb/glass) starting with
extent0.seaside.dbf in GS 2.4.4.4. thirdPartyMonticelloRepository is a
variable pointing to a local directory repository containing mcz's.
Does this approach make sense?

I start with updating metacello:
    Gofer it
        repository: thirdPartyMonticelloRepository;
        package: 'ConfigurationOfMetacello';
        package: 'ConfigurationOfGsMisc';     "If I don't do this,
loading glass later on breaks"
        load.

and then (in short):

   project := ConfigurationOfMetacello project.
   version := (project version: '1.0-beta.32')
        repositoryOverrides: {thirdPartyMonticelloRepository};
        load

then load glass:

   Metacello new
      baseline: 'GLASS1';
      repository: 'filetree://<local clone of
github.com/glassdb/glass>/repository';
      onUpgrade: [ :ex :existing :new | <print stuff>. ex allow ];
      onDowngrade: [ :ex :existing :new | <print ! Blocking
downgrade>. ex disallow ];
      load

Some questions.

1. During this load, I get a lot of downgrade attempts. For example:
"! Blocking downgrade Gofer 1.0.5.1 -> Gofer 1.0.2". Why this? We're
trying to load from a filetree.
2. I get "redirecting to
http://seaside.gemtalksystems.com/ss/announcements/Announcements.g-dkh.15.mcz",
for example. If I look in the filetree repo, Announcements.g is on
version dkh.16. So why try to load dkh.15?

I suspect this is because we have a ConfigurationOf and BaselineOf mix
that does not work together. Is there a way to override the versioning
in a ConfigurationOf class?

Thanks
Otto
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Otto,

I can imagine that you will be getting mixed results when trying to use GLASS1 with other packages ... You do an explicit load of ConfigurationOfGsMisc which is also covered by packages in GLASS1 and that may be confusing things ... The Gofer versions must be coming from Metacello and you are not necessarily using the latest and greatest Metacello Preview release ... you could try:

 Metacello new
  baseline: 'Metacello';
  repository: 'github://dalehenrich/metacello-work:master/repository';
  load: 'ALL'.
  ] on: Warning
    do: [:ex |
      Transcript cr; show: ex description.
      ex resume].

Instead of loading 1.0-beta.32 of Metacello ... Of course, you should make a local clone of Metacello and reference it as well ...

Instead of using repository overrides, I think that you should use `project locks`[1]. By using `locks` you will be able to point directly at your cloned repositories instead of having to maintain a monster thirdparty mcz repo...which is more important for the git-based repos ...

The announcements references are probably coming from direct references to the GsMisc project ....I'm  a bit worried about the fact that I know that there are references in a lot of the extant configurations to specific versions of ConfigurationOfGs* projects that will also potentially cause this kind of confusion and of course moving forward we will want to be able to reference particular versions of the GLASS1 repository that are required...

I think that the best answer will be that we'll actually need to change how the GLASS dependencies are referenced from the various projects when using GLASS1 because we want to reference the version of GLASS1 instead of the versions of the various sub projects ...

I also don't like the name GLASS1 and have been considering a rename to something more descriptive like GsWebEdition(?)...Seaside hasn't been included in the GLASS project for quite some time, so the GLASS acronym is a bit confusing for folks ...

To do this correctly, we'd need to invent new platform attributes when using GsWebEdition (I'll use this name for now) so that the metacello configs can be correctly editted, Instead of:

   gemstone, gemstone2.4.x, gemstone3.x, etc.

we'd use

  gswebedition, gswebedition2.4.x, gswebedition3.x, etc.

I think this would give us the cleanest break ... It entails editting a bunch of configurations, but I the move to GsWebEdition is a pretty significant move and I think warrants this kind of treatment ...

Fortunately, I'm getting close to finished with the internal GemStone work I've been spending most of my time on so I should have more time to devote to working on this transition...

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: [hidden email]
| Sent: Friday, November 15, 2013 3:27:08 AM
| Subject: [Glass] loading glass questions
|
| Hi,
|
| I'm loading GLASS (cloned from github.com/glassdb/glass) starting
| with
| extent0.seaside.dbf in GS 2.4.4.4. thirdPartyMonticelloRepository is
| a
| variable pointing to a local directory repository containing mcz's.
| Does this approach make sense?
|
| I start with updating metacello:
|     Gofer it
|         repository: thirdPartyMonticelloRepository;
|         package: 'ConfigurationOfMetacello';
|         package: 'ConfigurationOfGsMisc';     "If I don't do this,
| loading glass later on breaks"
|         load.
|
| and then (in short):
|
|    project := ConfigurationOfMetacello project.
|    version := (project version: '1.0-beta.32')
|         repositoryOverrides: {thirdPartyMonticelloRepository};
|         load
|
| then load glass:
|
|    Metacello new
|       baseline: 'GLASS1';
|       repository: 'filetree://<local clone of
| github.com/glassdb/glass>/repository';
|       onUpgrade: [ :ex :existing :new | <print stuff>. ex allow ];
|       onDowngrade: [ :ex :existing :new | <print ! Blocking
| downgrade>. ex disallow ];
|       load
|
| Some questions.
|
| 1. During this load, I get a lot of downgrade attempts. For example:
| "! Blocking downgrade Gofer 1.0.5.1 -> Gofer 1.0.2". Why this? We're
| trying to load from a filetree.
| 2. I get "redirecting to
| http://seaside.gemtalksystems.com/ss/announcements/Announcements.g-dkh.15.mcz",
| for example. If I look in the filetree repo, Announcements.g is on
| version dkh.16. So why try to load dkh.15?
|
| I suspect this is because we have a ConfigurationOf and BaselineOf
| mix
| that does not work together. Is there a way to override the
| versioning
| in a ConfigurationOf class?
|
| Thanks
| Otto
| _______________________________________________
| Glass mailing list
| [hidden email]
| http://lists.gemtalksystems.com/mailman/listinfo/glass
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Thanks for the help

> I can imagine that you will be getting mixed results when trying to use GLASS1 with other packages ... You do an explicit load of ConfigurationOfGsMisc which is also covered by packages in GLASS1 and that may be confusing things

I start off with a seaside database (or should I do the whole
bootstrapping thing myself?) or with a production database, which will
always have other MC & glass packages in there.

Well, if I don't load ConfigurationOfGsMisc, things break. I get a
MetacelloVersionDoesNotExistError, versionString = 0.241.1, seemingly
on ConfigurationOfGsMisc, something to do with
System-Digital-Signatures. And this is probably because there is an
old ConfigurationOfGsMisc loaded already.

I've encountered this a few times. ConfigurationOf classes are not
updated as they are encountered. I have to load them beforehand.

At this point in time, Metacello does not exist in my DB, but
monticello does. So I'm trying to get it in. Filetree is not
bootstrapped either. How do I get it in then? Issue is bootstrapping
of filetree + metacello. Currently use seaside image, with Monticello
and load from package files stored in a git repo.

> Instead of using repository overrides, I think that you should use `project locks`[1]. By using `locks` you will be able to point directly at your cloned repositories instead of having to maintain a monster thirdparty mcz repo...which is more important for the git-based repos ...

I don't know where to do this. I've got 1 class called
ConfigurationOfWonkaRuntime. (Yes, don't laugh, the project name is
Wonka). Runtime is all the base stuff we use like seaside & magritte.
So in there, I've got:

                        baseline: 'Seaside'
                            with: [
                                    spec
                                        className: 'BaselineOfSeaside30';
                                        repository: self class
localThirdPartySeasideRepository;
                                        loads: #('Base'
'Scriptaculous-Components' 'JQuery-UI') ];

and later on

                        project: 'Magritte3 Base'
                            with: [
                                    spec
                                        className: 'ConfigurationOfMagritte3';
                                        loads: #('Magritte-Seaside'
'Deprecated');
                                        repository:
'http://www.squeaksource.com/MetacelloRepository' ];

which defines a dependency on seaside 30.

This is really confusing. I wish I could just switch all this off. I
don't want Metacello to remember any repository, or where a package
came from. I want to just tell it where the packages are and it must
just use that. I *never* want it to fetch *any* package from a remote
repo. This is pain. I don't understand.

To me, it is quite simple.
- We use git.
- Or for that matter, any old version control system.
- We take a snapshot (read git commit) of all the software, image
files, scripts and configs that work together.
- That's a version.
- We want to deploy *that* version. (deploy = upgrade existing / build
new db on a bootstrapped one)
- Reliably.
- We can't depend on github or n external repositories. We want to
know that once a particular version is checked out, it will deploy.
- We have all the packages we've tested manually and have run through
our tests together in a version
- We don't want any package caching. Just get it from disk.
- We don't want fancy upgrading of packages, just delete all the code
and load from scratch (Upgrading of packages almost never work as
overridden methods are removed.)
- We don't want to specify a version of any package anywhere because
we've got the version we want in the repo

Pardon the dump. We seem to have conflicting approaches. I don't
understand how people can get a reliably working system in any other
way. Please enlighten me (no sarcasm intended). We've been trying to
upgrade this stuff for 1 year now. This is way too costly, and
frustrating.

Yes, agree with all of the above.

> Fortunately, I'm getting close to finished with the internal GemStone work I've been spending most of my time on so I should have more time to devote to working on this transition...

Thanks for all your effort.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Otto,

My short answer is that your rant is absolutely valid. With the Metacello Preview I am actually attempting to achieve exactly what you are asking for ... From my perspective it should be possible for a team to fork the git repos for all of the external projects that they depend upon then do project loads without having to edit every single configuration or baseline that references the project ... If I'm not mistaken this is exactly what you are looking for...

The long answer is that we have to address a couple of fundamental questions:

 1. does the Metacello Preview actually meet your needs, or am I on crack?
 2. how do you get FileTree and Metacello Preview loaded?
 3. what will you need to change in your current environment to take
    advantage of the Metacello Preview?

I think we need to take these questions one at a time ...

I can put together an example of how you can leverage the Metacello Preview. In the example, I will set up a sample local project that references one project on github and another project on ss3. Then show the steps where you can:

  a) fork the github-based repo to your local disk;
  b) copy the ss3 project to a disk based repository; and
  c) arrange to do a load without having to edit any of the configurations ...

If I'm not mistaken, this is the kind of thing you want to do ... if I am mistaken, we can tweak the example so that it matches your needs and then make sure that the Metacello Preview operates to your satisfaction ...

Once you've seen and played with a working example, we can start tackling the other questions ...

So what do you think?

I'm going to start working on the examples right now...

Dale

| From: "Otto Behrens" <[hidden email]>
| To: "Dale K. Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Sunday, November 17, 2013 11:52:50 AM
| Subject: Re: [Glass] loading glass questions
|
| Thanks for the help
|
| > I can imagine that you will be getting mixed results when trying to
| > use GLASS1 with other packages ... You do an explicit load of
| > ConfigurationOfGsMisc which is also covered by packages in GLASS1
| > and that may be confusing things
|
| I start off with a seaside database (or should I do the whole
| bootstrapping thing myself?) or with a production database, which
| will
| always have other MC & glass packages in there.
|
| Well, if I don't load ConfigurationOfGsMisc, things break. I get a
| MetacelloVersionDoesNotExistError, versionString = 0.241.1, seemingly
| on ConfigurationOfGsMisc, something to do with
| System-Digital-Signatures. And this is probably because there is an
| old ConfigurationOfGsMisc loaded already.
|
| I've encountered this a few times. ConfigurationOf classes are not
| updated as they are encountered. I have to load them beforehand.
|
| >  Metacello new
| >   baseline: 'Metacello';
| >   repository:
| >   'github://dalehenrich/metacello-work:master/repository';
| >   load: 'ALL'.
| >   ] on: Warning
| >     do: [:ex |
| >       Transcript cr; show: ex description.
| >       ex resume].
| >
| > Instead of loading 1.0-beta.32 of Metacello ... Of course, you
| > should make a local clone of Metacello and reference it as well
| > ...
|
| At this point in time, Metacello does not exist in my DB, but
| monticello does. So I'm trying to get it in. Filetree is not
| bootstrapped either. How do I get it in then? Issue is bootstrapping
| of filetree + metacello. Currently use seaside image, with Monticello
| and load from package files stored in a git repo.
|
| > Instead of using repository overrides, I think that you should use
| > `project locks`[1]. By using `locks` you will be able to point
| > directly at your cloned repositories instead of having to maintain
| > a monster thirdparty mcz repo...which is more important for the
| > git-based repos ...
|
| I don't know where to do this. I've got 1 class called
| ConfigurationOfWonkaRuntime. (Yes, don't laugh, the project name is
| Wonka). Runtime is all the base stuff we use like seaside & magritte.
| So in there, I've got:
|
|                         baseline: 'Seaside'
|                             with: [
|                                     spec
|                                         className:
|                                         'BaselineOfSeaside30';
|                                         repository: self class
| localThirdPartySeasideRepository;
|                                         loads: #('Base'
| 'Scriptaculous-Components' 'JQuery-UI') ];
|
| and later on
|
|                         project: 'Magritte3 Base'
|                             with: [
|                                     spec
|                                         className:
|                                         'ConfigurationOfMagritte3';
|                                         loads: #('Magritte-Seaside'
| 'Deprecated');
|                                         repository:
| 'http://www.squeaksource.com/MetacelloRepository' ];
|
| which defines a dependency on seaside 30.
|
| This is really confusing. I wish I could just switch all this off. I
| don't want Metacello to remember any repository, or where a package
| came from. I want to just tell it where the packages are and it must
| just use that. I *never* want it to fetch *any* package from a remote
| repo. This is pain. I don't understand.
|
| To me, it is quite simple.
| - We use git.
| - Or for that matter, any old version control system.
| - We take a snapshot (read git commit) of all the software, image
| files, scripts and configs that work together.
| - That's a version.
| - We want to deploy *that* version. (deploy = upgrade existing /
| build
| new db on a bootstrapped one)
| - Reliably.
| - We can't depend on github or n external repositories. We want to
| know that once a particular version is checked out, it will deploy.
| - We have all the packages we've tested manually and have run through
| our tests together in a version
| - We don't want any package caching. Just get it from disk.
| - We don't want fancy upgrading of packages, just delete all the code
| and load from scratch (Upgrading of packages almost never work as
| overridden methods are removed.)
| - We don't want to specify a version of any package anywhere because
| we've got the version we want in the repo
|
| Pardon the dump. We seem to have conflicting approaches. I don't
| understand how people can get a reliably working system in any other
| way. Please enlighten me (no sarcasm intended). We've been trying to
| upgrade this stuff for 1 year now. This is way too costly, and
| frustrating.
|
| > I think that the best answer will be that we'll actually need to
| > change how the GLASS dependencies are referenced from the various
| > projects when using GLASS1 because we want to reference the
| > version of GLASS1 instead of the versions of the various sub
| > projects ...
| >
| > I also don't like the name GLASS1 and have been considering a
| > rename to something more descriptive like
| > GsWebEdition(?)...Seaside hasn't been included in the GLASS
| > project for quite some time, so the GLASS acronym is a bit
| > confusing for folks ...
| >
| > To do this correctly, we'd need to invent new platform attributes
| > when using GsWebEdition (I'll use this name for now) so that the
| > metacello configs can be correctly editted, Instead of:
| >
| >    gemstone, gemstone2.4.x, gemstone3.x, etc.
| >
| > we'd use
| >
| >   gswebedition, gswebedition2.4.x, gswebedition3.x, etc.
| >
| > I think this would give us the cleanest break ... It entails
| > editting a bunch of configurations, but I the move to GsWebEdition
| > is a pretty significant move and I think warrants this kind of
| > treatment ...
|
| Yes, agree with all of the above.
|
| > Fortunately, I'm getting close to finished with the internal
| > GemStone work I've been spending most of my time on so I should
| > have more time to devote to working on this transition...
|
| Thanks for all your effort.
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Thanks Dale, such an example will be helpful. I did not expect of you
to jump in right now and do this, thanks.
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I'll do what I can, but I really have targetted the Metacello Preview to address exactly the problems you are experiencing and I believe in striking while the iron is hot ... so I'm part way to building an example and will need to do some gemstone product work tomorrow:)

Dale

----- Original Message -----
| From: "Otto Behrens" <[hidden email]>
| To: "Dale K. Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Sunday, November 17, 2013 6:45:08 PM
| Subject: Re: [Glass] loading glass questions
|
| Thanks Dale, such an example will be helpful. I did not expect of you
| to jump in right now and do this, thanks.
|
| > My short answer is that your rant is absolutely valid. With the
| > Metacello Preview I am actually attempting to achieve exactly what
| > you are asking for ... From my perspective it should be possible
| > for a team to fork the git repos for all of the external projects
| > that they depend upon then do project loads without having to edit
| > every single configuration or baseline that references the project
| > ... If I'm not mistaken this is exactly what you are looking
| > for...
| >
| > The long answer is that we have to address a couple of fundamental
| > questions:
| >
| >  1. does the Metacello Preview actually meet your needs, or am I on
| >  crack?
| >  2. how do you get FileTree and Metacello Preview loaded?
| >  3. what will you need to change in your current environment to
| >  take
| >     advantage of the Metacello Preview?
| >
| > I think we need to take these questions one at a time ...
| >
| > I can put together an example of how you can leverage the Metacello
| > Preview. In the example, I will set up a sample local project that
| > references one project on github and another project on ss3. Then
| > show the steps where you can:
| >
| >   a) fork the github-based repo to your local disk;
| >   b) copy the ss3 project to a disk based repository; and
| >   c) arrange to do a load without having to edit any of the
| >   configurations ...
| >
| > If I'm not mistaken, this is the kind of thing you want to do ...
| > if I am mistaken, we can tweak the example so that it matches your
| > needs and then make sure that the Metacello Preview operates to
| > your satisfaction ...
| >
| > Once you've seen and played with a working example, we can start
| > tackling the other questions ...
| >
| > So what do you think?
| >
| > I'm going to start working on the examples right now...
| >
| > Dale
| >
| > | From: "Otto Behrens" <[hidden email]>
| > | To: "Dale K. Henrichs" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Sunday, November 17, 2013 11:52:50 AM
| > | Subject: Re: [Glass] loading glass questions
| > |
| > | Thanks for the help
| > |
| > | > I can imagine that you will be getting mixed results when
| > | > trying to
| > | > use GLASS1 with other packages ... You do an explicit load of
| > | > ConfigurationOfGsMisc which is also covered by packages in
| > | > GLASS1
| > | > and that may be confusing things
| > |
| > | I start off with a seaside database (or should I do the whole
| > | bootstrapping thing myself?) or with a production database, which
| > | will
| > | always have other MC & glass packages in there.
| > |
| > | Well, if I don't load ConfigurationOfGsMisc, things break. I get
| > | a
| > | MetacelloVersionDoesNotExistError, versionString = 0.241.1,
| > | seemingly
| > | on ConfigurationOfGsMisc, something to do with
| > | System-Digital-Signatures. And this is probably because there is
| > | an
| > | old ConfigurationOfGsMisc loaded already.
| > |
| > | I've encountered this a few times. ConfigurationOf classes are
| > | not
| > | updated as they are encountered. I have to load them beforehand.
| > |
| > | >  Metacello new
| > | >   baseline: 'Metacello';
| > | >   repository:
| > | >   'github://dalehenrich/metacello-work:master/repository';
| > | >   load: 'ALL'.
| > | >   ] on: Warning
| > | >     do: [:ex |
| > | >       Transcript cr; show: ex description.
| > | >       ex resume].
| > | >
| > | > Instead of loading 1.0-beta.32 of Metacello ... Of course, you
| > | > should make a local clone of Metacello and reference it as well
| > | > ...
| > |
| > | At this point in time, Metacello does not exist in my DB, but
| > | monticello does. So I'm trying to get it in. Filetree is not
| > | bootstrapped either. How do I get it in then? Issue is
| > | bootstrapping
| > | of filetree + metacello. Currently use seaside image, with
| > | Monticello
| > | and load from package files stored in a git repo.
| > |
| > | > Instead of using repository overrides, I think that you should
| > | > use
| > | > `project locks`[1]. By using `locks` you will be able to point
| > | > directly at your cloned repositories instead of having to
| > | > maintain
| > | > a monster thirdparty mcz repo...which is more important for the
| > | > git-based repos ...
| > |
| > | I don't know where to do this. I've got 1 class called
| > | ConfigurationOfWonkaRuntime. (Yes, don't laugh, the project name
| > | is
| > | Wonka). Runtime is all the base stuff we use like seaside &
| > | magritte.
| > | So in there, I've got:
| > |
| > |                         baseline: 'Seaside'
| > |                             with: [
| > |                                     spec
| > |                                         className:
| > |                                         'BaselineOfSeaside30';
| > |                                         repository: self class
| > | localThirdPartySeasideRepository;
| > |                                         loads: #('Base'
| > | 'Scriptaculous-Components' 'JQuery-UI') ];
| > |
| > | and later on
| > |
| > |                         project: 'Magritte3 Base'
| > |                             with: [
| > |                                     spec
| > |                                         className:
| > |                                         'ConfigurationOfMagritte3';
| > |                                         loads:
| > |                                         #('Magritte-Seaside'
| > | 'Deprecated');
| > |                                         repository:
| > | 'http://www.squeaksource.com/MetacelloRepository' ];
| > |
| > | which defines a dependency on seaside 30.
| > |
| > | This is really confusing. I wish I could just switch all this
| > | off. I
| > | don't want Metacello to remember any repository, or where a
| > | package
| > | came from. I want to just tell it where the packages are and it
| > | must
| > | just use that. I *never* want it to fetch *any* package from a
| > | remote
| > | repo. This is pain. I don't understand.
| > |
| > | To me, it is quite simple.
| > | - We use git.
| > | - Or for that matter, any old version control system.
| > | - We take a snapshot (read git commit) of all the software, image
| > | files, scripts and configs that work together.
| > | - That's a version.
| > | - We want to deploy *that* version. (deploy = upgrade existing /
| > | build
| > | new db on a bootstrapped one)
| > | - Reliably.
| > | - We can't depend on github or n external repositories. We want
| > | to
| > | know that once a particular version is checked out, it will
| > | deploy.
| > | - We have all the packages we've tested manually and have run
| > | through
| > | our tests together in a version
| > | - We don't want any package caching. Just get it from disk.
| > | - We don't want fancy upgrading of packages, just delete all the
| > | code
| > | and load from scratch (Upgrading of packages almost never work as
| > | overridden methods are removed.)
| > | - We don't want to specify a version of any package anywhere
| > | because
| > | we've got the version we want in the repo
| > |
| > | Pardon the dump. We seem to have conflicting approaches. I don't
| > | understand how people can get a reliably working system in any
| > | other
| > | way. Please enlighten me (no sarcasm intended). We've been trying
| > | to
| > | upgrade this stuff for 1 year now. This is way too costly, and
| > | frustrating.
| > |
| > | > I think that the best answer will be that we'll actually need
| > | > to
| > | > change how the GLASS dependencies are referenced from the
| > | > various
| > | > projects when using GLASS1 because we want to reference the
| > | > version of GLASS1 instead of the versions of the various sub
| > | > projects ...
| > | >
| > | > I also don't like the name GLASS1 and have been considering a
| > | > rename to something more descriptive like
| > | > GsWebEdition(?)...Seaside hasn't been included in the GLASS
| > | > project for quite some time, so the GLASS acronym is a bit
| > | > confusing for folks ...
| > | >
| > | > To do this correctly, we'd need to invent new platform
| > | > attributes
| > | > when using GsWebEdition (I'll use this name for now) so that
| > | > the
| > | > metacello configs can be correctly editted, Instead of:
| > | >
| > | >    gemstone, gemstone2.4.x, gemstone3.x, etc.
| > | >
| > | > we'd use
| > | >
| > | >   gswebedition, gswebedition2.4.x, gswebedition3.x, etc.
| > | >
| > | > I think this would give us the cleanest break ... It entails
| > | > editting a bunch of configurations, but I the move to
| > | > GsWebEdition
| > | > is a pretty significant move and I think warrants this kind of
| > | > treatment ...
| > |
| > | Yes, agree with all of the above.
| > |
| > | > Fortunately, I'm getting close to finished with the internal
| > | > GemStone work I've been spending most of my time on so I should
| > | > have more time to devote to working on this transition...
| > |
| > | Thanks for all your effort.
| > |
|
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass