Envy and Continuous Integration
Guillermo Schwarz
Has anyone done that before?
Cheers,
Guillermo Schwarz.
Joseph Pelrine
Look at "Mastering ENVY/Developer", pp. 93-96.
Cheers
--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrin...@metaprog.com
Web: http://www.metaprog.com
"If you don't live on the edge, you're taking up too much space" -
Doug Robinson
--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrin...@metaprog.com
Web: http://www.metaprog.com
"If you don't live on the edge, you're taking up too much space" -
Doug Robinson
Ron Jeffries
<guillerm...@hotmail.com> wrote:
>How can we do continuous integration using Envy?
>
>Has anyone done that before?
Uh, yes. The first XP project did it. I'm wondering why you might be having
difficulty. In brief, here's what we did. It has been a while, I'm not sure that
I'll be using the words correctly, but I hope you'll get the drift.
1. Everyone had access to everything in the config.
2. Pairs worked in their own sandbox, making all the tests work.
3. When they were ready to release (every couple of hours) they would version
their stuff. Then they would go to the integration machine, load the config,
load their version, run the tests. If the tests ran, they would commit their
stuff into the config (version the config?)
Joseph's book is just what you need for the details.
Regards,
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Guillermo Schwarz
"Ron Jeffries" <ronje...@REMOVEacm.org> escribió en el mensaje
news:udsfovoocne4k9668...@4ax.com...
> On Tue, 7 Oct 2003 22:40:17 -0400, "Guillermo Schwarz"
> <guillerm...@hotmail.com> wrote:
>
> >How can we do continuous integration using Envy?
> >
> >Has anyone done that before?
>
> Uh, yes. The first XP project did it. I'm wondering why you might be
having
> difficulty. In brief, here's what we did. It has been a while, I'm not
sure that
> I'll be using the words correctly, but I hope you'll get the drift.
>
> 1. Everyone had access to everything in the config.
> 2. Pairs worked in their own sandbox, making all the tests work.
> 3. When they were ready to release (every couple of hours) they would
version
> their stuff. Then they would go to the integration machine, load the
config,
> load their version, run the tests.
They would actually walk there and do manually all that stuff? I've done the
same using CVS and it was fully automated. Besides, what is the point of
doing all this if there is no "build number" concept in ENVY?
> If the tests ran, they would commit their
> stuff into the config (version the config?)
I have no idea what the config is. They already versioned their classes,
shouldn't they now release their classes?
>
> Joseph's book is just what you need for the details.
Thanks.
Ron Jeffries
<guillerm...@hotmail.com> wrote:
>
>"Ron Jeffries" <ronje...@REMOVEacm.org> escribió en el mensaje
>news:udsfovoocne4k9668...@4ax.com...
>> On Tue, 7 Oct 2003 22:40:17 -0400, "Guillermo Schwarz"
>> <guillerm...@hotmail.com> wrote:
>>
>> >How can we do continuous integration using Envy?
>> >
>> >Has anyone done that before?
>>
>> Uh, yes. The first XP project did it. I'm wondering why you might be
>having
>> difficulty. In brief, here's what we did. It has been a while, I'm not
>sure that
>> I'll be using the words correctly, but I hope you'll get the drift.
>>
>> 1. Everyone had access to everything in the config.
>> 2. Pairs worked in their own sandbox, making all the tests work.
>> 3. When they were ready to release (every couple of hours) they would
>version
>> their stuff. Then they would go to the integration machine, load the
>config,
>> load their version, run the tests.
>
>They would actually walk there and do manually all that stuff? I've done the
>same using CVS and it was fully automated. Besides, what is the point of
>doing all this if there is no "build number" concept in ENVY?
To get the system integrated, and to serialize integrations, so that each one
includes just the work of one pair. Not necessary, but we liked it that way.
>
>> If the tests ran, they would commit their
>> stuff into the config (version the config?)
>
>I have no idea what the config is. They already versioned their classes,
>shouldn't they now release their classes?
I guess you don't use Envy at all, is that right?
Sascha D?rdelmann
> How can we do continuous integration using Envy?
>
> Has anyone done that before?
Yes. And we did it in a way the envy developers wouldn't like but it
worked fine for a couple of years.
(I assume you don't mean the configuration management tool continuous
but "continuous integration" in means of a rolling baseline.)
We had one open edition of one configuartion map for each project
release and a release guideline for this map:
- We did not allow to release open editions of applications.
- We did not allow the release of base system patches into this map.
Instead we had a second map and a special base image to handle that.
- We did not allow anybody to create new applications without
informing the person responsible for configuration management in the
project.
Notice, that you hardly need any dayly builds with this strategy.
Developers usually upgrade by simply reloading applications of the
open edition.
Taking these basic guidelines we introduced further rules to handle
code ownership, control of proper prerequisite settings and build
management. We even added some convenience functions to the envy
browsers. For example we added a 'savely release' to prevent
overwrites in a CVS like manner. And we told the ImageMaker to store
some version informations in the production image to be able to
reproduce the build version. Other tools where a graph view of
application dependencies and a graph view of the edition history.
After all we ended with something very easy to handle for members of
our team. The pitfall was that you had to explain everything to
anybody who was used to the standard envy style as described in the
envy documentation. The envy documentation tells you to change your
configuration management in ways envy is best suited for. Ok, we
didn't do that. We changed some minor things and after all, envy did
what we wanted it to.
Having said that, I have to add that envy is a great tool. You won't
ever need any changes in the core envy system. I strongly recommend
that you leave it as it is. If you feel that you have to change
anything at all, some minor adds in the IDE will normaly do.
Cheers,
Sascha
Guillermo Schwarz
In our case, a developer finishes a task, what did him modify? Envy doesn't
tell you. In our case the projects are huge mostly because we are more than
10 developers, there are other teams and the legacy code is huge, so finding
what I modified is a daunting task. If I do not inform other developers,
they will probably never know, because Envy doesn't have AFAIK something
like CVS update.
Besides by default Envy branches each class if you don't start with the last
class version. This reminds me the subversion designers decided that "every
tag is a branch tag", because it becomes hellish. It is really annoying that
you have to remember to update each class before touching it. Besides there
is no "uncheckout" command, so you must check it in aas "bad" or something
like that. Besides there is no automatic merge like in CVS, and that means
that sometimes a developer overwrites what somebody else has done. That's
not pretty. Maybe the "savely relese" would help, what did it do? Maybe I
can reproduce it. I have yet to understand how to create something like
that.
Besides how can you tag the whole project to produce a build? I think Envy
can't. Then upgrading to the latest release is similar, but somebody has to
spend some time compiling everything (or taking a look at every class to see
if it compiles) and then run some tests, manually, since there is no way to
automate running the tests, AFAIK. Then after a day or two, we could version
the project and call that a build, but that would be too cumbersome.
We haven't released anything yet, since the project is 100% waterfall + some
iterations at the end because the system won't work as expected. There are
no unit tests because we use VA4J and that compiles everything without any
ant file, so we can't tell VA4J to run some tests after compiling, unless we
decide to spend some time creating huge ant file, never mind, that's not
likely to ever happen unless we upgrade to WAD.
Cheers and thanks for your help,
Guillermo Schwarz.
"Sascha D?rdelmann" <ws...@onlinehome.de> escribió en el mensaje
news:a39cf4fe.03101...@posting.google.com...
Isaac Gouy
> It is interesting how you did it, but there are so many loose ends.
>
> In our case, a developer finishes a task, what did him modify? Envy doesn't
> tell you. In our case the projects are huge mostly because we are more than
> 10 developers, there are other teams and the legacy code is huge, so finding
> what I modified is a daunting task. If I do not inform other developers,
> they will probably never know, because Envy doesn't have AFAIK something
> like CVS update.
Ummm, aren't you versioning applications and classes?
> Besides by default Envy branches each class if you don't start with the last
> class version. This reminds me the subversion designers decided that "every
> tag is a branch tag", because it becomes hellish. It is really annoying that
> you have to remember to update each class before touching it.
Ummm, seem to remember that you can load all released versions in a
single step?
> Besides there
> is no "uncheckout" command, so you must check it in aas "bad" or something
> like that.
Ummm, if you don't want the "bad" edition, just leave them as
open-editions - don't version them, don't release them.
> Besides there is no automatic merge like in CVS, and that means
> that sometimes a developer overwrites what somebody else has done.
Ummm, simple release process - each developer diffs the version they
wish to release against the current released version, and merges
before releasing. (Maybe they should write more shorter-methods?)
> That's
> not pretty. Maybe the "savely relese" would help, what did it do? Maybe I
> can reproduce it. I have yet to understand how to create something like
> that.
>
> Besides how can you tag the whole project to produce a build? I think Envy
> can't. Then upgrading to the latest release is similar, but somebody has to
> spend some time compiling everything (or taking a look at every class to see
> if it compiles) and then run some tests, manually, since there is no way to
> automate running the tests, AFAIK.
Ummm, seem to remember selecting class editions from lists in Envy
Smalltalk browser windows - if a browser window can populate a list of
class editions within Smalltalk, what's to stop you writing Smalltalk
doIt script that grabs all the latest versions, loading them into a
test image, and running SUnit tests?
> Then after a day or two, we could version
> the project and call that a build, but that would be too cumbersome.
>
> We haven't released anything yet, since the project is 100% waterfall + some
> iterations at the end because the system won't work as expected.
Can't blame Envy for that.
> There are
> no unit tests because we use VA4J and that compiles everything without any
> ant file, so we can't tell VA4J to run some tests after compiling, unless we
> decide to spend some time creating huge ant file, never mind, that's not
> likely to ever happen unless we upgrade to WAD.
afaik TDD enthusiasts expect to write as many lines of test code as
app code. True enough, it's difficult to do automated unit tests
without writing test code.
Alan Knight
things. It doesn't do things the way that systems like CVS do, but that
just means the mechanisms are different, not that they don't exist. I'd
suggest a good book on ENVY might be helpful (e.g. "Mastering
ENVY/Developer"). Of course, since you're using VA/Java you have less
access to the internals and less ability to automate, but I suspect many
of these things are still automatable. I also note in passing that, to
the best of my knowledge, the term "continuous integration" was coined
with respect to ENVY.
Finding out what you modified is easy, it's the list of open class
editions. You can either see these graphically, or you have queries that
will give you a list (I'm pretty sure these are also in VA/J). If you
have a hard time remembering, continuous integration seems to suggest you
should be working in smaller increments.
The ENVY application manager indicates, normally with a leading ">"
beside a class if you are not working with the released version.
ENVY is based around class ownership, which tends to alleviate issues of
informing others, because class release must always go through an
individual. This process doesn't suit everyone, and XP practice is
usually to work as a single user. But reloading the current open edition
of the config map works rather nicely as a way of updating before you
start to touch things.
There is no check in or check out operation at all in ENVY. If you don't
like what you've done in an open class edition, don't version it. The
repository will end up with junk in it, but that's OK and a natural
consequence of a repository that immediately reflects every change that's
made rather than waiting for you to "check in".
"Tagging the whole project" is what config maps are for. VA/Java has a
different name for these (maybe Project?). I'm sorry you find versioning
to cumbersome.
It seems like you're deeply in a CVS and ant mindset. It might be a good
idea to read up on how ENVY approaches things and/or how XP processes
have been used in this environment. Since the original XUnit was created
and used in this environment, it's just possible that ENVY doesn't
entirely preclude using unit tests.
"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in
news:3f99dd8f$1...@news.totallyobjects.com:
--
Alan Knight [|], Cincom Smalltalk Development
kni...@acm.org
akn...@cincom.com
http://www.cincom.com/smalltalk
"I believe that many of the systems we build today in Java would be
better built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003
Eric Clayberg
news:3f99dd8f$1...@news.totallyobjects.com...
>
> In our case, a developer finishes a task, what did him modify? Envy
doesn't
> tell you.
Sure it does. That is what all of those open editions represent. If you have
VA Assist loaded, they are all marked blue so they are easy to see.
http://www.instantiations.com/assist/
http://www.instantiations.com/assist/
> In our case the projects are huge mostly because we are more than
> 10 developers
ENVY is ideal for extremely large teams of developers. I have worked on
projects that had several hundred simultaneous ENVY users.
> so finding what I modified is a daunting task.
Why? That should be trivial. VA Java (which you are using) even includes
some nice tools that will tell you that directly. VA Assist adds in quite a
bit of additional capability on top of that.
> Besides by default Envy branches each class if you don't start with the
last
> class version. This reminds me the subversion designers decided that
"every
> tag is a branch tag", because it becomes hellish.
Hellish? Only if you are trying to shoehorn ENVY into a CVS mindset. ENVY
has been used to build some of the worlds largest IT applications for the
banking, insurance and telecom industries (and many others).
> It is really annoying that you have to remember to update each class
before touching it.
You only need to update, if you aren't using the most recent version of a
class. VA Assist will automatically tell you that, if you try to modify a
class that has a newer edition in the repository.
> Besides how can you tag the whole project to produce a build?
What's wrong with just versioning it?
> Then upgrading to the latest release is similar, but somebody has to
> spend some time compiling everything (or taking a look at every class to
see
> if it compiles) and then run some tests, manually, since there is no way
to
> automate running the tests, AFAIK.
You could use VA Assist to automate almost anything in VA Java including
running JUnit tests.
-Eric Clayberg
Sr. Vice President of Product Development
Instantiations, Inc.
http://www.instantiations.com
http://www.instantiations.com/assist/
http://www.instantiations.com/sts
Eric Clayberg
news:Xns941F88F66E0...@66.185.95.104...
> I think you're missing a few of the important concepts of how ENVY does
> things. It doesn't do things the way that systems like CVS do, but that
> just means the mechanisms are different, not that they don't exist. I'd
> suggest a good book on ENVY might be helpful (e.g. "Mastering
> ENVY/Developer"). Of course, since you're using VA/Java you have less
> access to the internals and less ability to automate, but I suspect many
> of these things are still automatable.
...especially if you have VA Assist loaded. ;-)
> Finding out what you modified is easy, it's the list of open class
> editions. You can either see these graphically, or you have queries that
> will give you a list (I'm pretty sure these are also in VA/J).
Yes. VAJ actually does a very good job with that. VA Assist adds in dozens
of additional queries.
> ENVY is based around class ownership, which tends to alleviate issues of
> informing others, because class release must always go through an
> individual. This process doesn't suit everyone, and XP practice is
> usually to work as a single user. But reloading the current open edition
> of the config map works rather nicely as a way of updating before you
> start to touch things.
VA Assist even adds an option that will warn you if you try to create an
open (or scratch) edition of a class that has a new edition in the
repository.
Guillermo Schwarz
"Isaac Gouy" <ig...@yahoo.com> escribió en el mensaje
news:ce7ef1c8.03102...@posting.google.com...
> "Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in
message news:<3f99dd8f$1...@news.totallyobjects.com>...
> > It is interesting how you did it, but there are so many loose ends.
> >
> > In our case, a developer finishes a task, what did him modify? Envy
doesn't
> > tell you. In our case the projects are huge mostly because we are more
than
> > 10 developers, there are other teams and the legacy code is huge, so
finding
> > what I modified is a daunting task. If I do not inform other developers,
> > they will probably never know, because Envy doesn't have AFAIK something
> > like CVS update.
>
> Ummm, aren't you versioning applications and classes?
Yes, I am. Let us suppose developer 1 generates version 1, 2 and 3 of class
A and version 2 of class B. Then developer 2 generates version 4 of class A,
version 3 of class B and version 5 of class C.
How do I know which versions should I use if I want to develop something?
Should I browse ENVY to see who has modified what? That would be very time
consuming. There is no way to get up to date without asking every developer
what have they modified.
OTOH in CVS I just select CVS update and voila, everything is up to date.
>
> > Besides by default Envy branches each class if you don't start with the
last
> > class version. This reminds me the subversion designers decided that
"every
> > tag is a branch tag", because it becomes hellish. It is really annoying
that
> > you have to remember to update each class before touching it.
>
> Ummm, seem to remember that you can load all released versions in a
> single step?
Yes, released versions, but no developer is required to get up to date
before releasing their stuff, as they are required on CVS, so it is easy in
ENVY to get versions messed up (individual classes are ok, but the whole
doesn't work).
>
> > Besides there
> > is no "uncheckout" command, so you must check it in aas "bad" or
something
> > like that.
>
> Ummm, if you don't want the "bad" edition, just leave them as
> open-editions - don't version them, don't release them.
Ok, that's a good alternative, but how can you remenber on what you were
working yesterday? Did you modify that file on purpose? Do you have to check
it in in order for the whole system to work?
>
> > Besides there is no automatic merge like in CVS, and that means
> > that sometimes a developer overwrites what somebody else has done.
>
> Ummm, simple release process - each developer diffs the version they
> wish to release against the current released version, and merges
> before releasing. (Maybe they should write more shorter-methods?)
Yes, you have to remenber to manually diff before versioning. That's great
for informal code reviews before check-in, but annoying if you don't need
code reviews.
>
> > That's
> > not pretty. Maybe the "savely relese" would help, what did it do? Maybe
I
> > can reproduce it. I have yet to understand how to create something like
> > that.
> >
> > Besides how can you tag the whole project to produce a build? I think
Envy
> > can't. Then upgrading to the latest release is similar, but somebody has
to
> > spend some time compiling everything (or taking a look at every class to
see
> > if it compiles) and then run some tests, manually, since there is no way
to
> > automate running the tests, AFAIK.
>
> Ummm, seem to remember selecting class editions from lists in Envy
> Smalltalk browser windows - if a browser window can populate a list of
> class editions within Smalltalk, what's to stop you writing Smalltalk
> doIt script that grabs all the latest versions, loading them into a
> test image, and running SUnit tests?
Well in this case it would be JUnit tests, I've done that using CVS and all
it required to verify the project in the repository was to check-in, press a
button in a web page and then the whole verification process was automatic.
Well, if I had an integration machine I could spend some time doing that,
but I get confused on how to verify that everything compiles. After that
running the tests shouldn't be hard.
>
> > Then after a day or two, we could version
> > the project and call that a build, but that would be too cumbersome.
> >
> > We haven't released anything yet, since the project is 100% waterfall +
some
> > iterations at the end because the system won't work as expected.
>
> Can't blame Envy for that.
HA HA HA, ;-)
well, it is just iterative only at the end because the first iteration is
rather long.
>
> > There are
> > no unit tests because we use VA4J and that compiles everything without
any
> > ant file, so we can't tell VA4J to run some tests after compiling,
unless we
> > decide to spend some time creating huge ant file, never mind, that's not
> > likely to ever happen unless we upgrade to WAD.
>
> afaik TDD enthusiasts expect to write as many lines of test code as
> app code.
I've been there done that and it works like a charm. It slows you down a
little bit because you end up making some mistakes that you detect before
the check-in and you spend some time fixing them, but the whole process is
several times faster when compared with waiting for other developers or the
customer to find the bugs and then trying to repro it to find the defective
code.
> True enough, it's difficult to do automated unit tests
> without writing test code.
Well, you can test it manually, and finally you will have to do that anyway
even if using JUnit.
Cheers,
Guillermo.
Eric Clayberg
>
> > Ummm, aren't you versioning applications and classes?
>
> Yes, I am. Let us suppose developer 1 generates version 1, 2 and 3 of
class
> A and version 2 of class B. Then developer 2 generates version 4 of class
A,
> version 3 of class B and version 5 of class C.
No problem. In addition to versioning the classes, can we assume that the
developer is releasing them, or the owner of the class is releasing the
correct version? If you want to make ENVY feel more like CVS, you should
always just version and release in the same step. If you consider the open
edition of your project to be similar to your HEAD stream, versioning and
releasing would be equivalent to committing. Versioning a class in ENVY is
*not* equivalent to committing in CVS. Versioning is basically locking down
a set of changes, giving them a name and then queuing them up for the class
owner to commit (release). If the class developer and class owner are the
same person, the version and release process can be done in one step (even
if they aren't the same person, you can set ENVY up so that the version and
release operation can be done in one step).
> How do I know which versions should I use if I want to develop something?
That's easy. Just use the released versions. That would be equivalent to
using the HEAD stream in CVS.
> Should I browse ENVY to see who has modified what?
No. You don't need to do that.
> There is no way to get up to date without asking every developer
> what have they modified.
Just re-load the current open edition of your project or package. That will
load the currently released editions into your workspace. That is the moral
equivalent of updating against the HEAD stream. You can easily have this
done automatically every time you start up VAJ. You can even have VAJ check
for new editions and automatically load them into your workspace every 15
minutes if you want to.
> OTOH in CVS I just select CVS update and voila, everything is up to date.
In ENVY, I just load the current edition and voila, everything is up to
date. Unless a version has been released into the current project or package
edition, it hasn't been committed yet (from a CVS point of view).
> Yes, released versions
The released versions are the same as the committed versions in CVS. If you
haven't got the ENVY version and release process under control, it is no
wonder you are having a hard time.
> but no developer is required to get up to date
> before releasing their stuff, as they are required on CVS
How does CVS *require* you to get up to date? I can easily commit a change
to CVS that is based on an older (wrong) version of a class.
> so it is easy in ENVY to get versions messed up
The only way to get things "messed up" is to misuse the system. ENVY has its
rules just like CVS does. Each requires its own unique process, and, if you
try to force one mindset onto the other, you will be very disappointed. When
I first started using CVS (after ten years of using ENVY), I was very
disappointed at how light weight it was relative to ENVY. I have gotten use
to it, and have no problem using it, but I do miss using ENVY on a daily
basis.
> > Ummm, if you don't want the "bad" edition, just leave them as
> > open-editions - don't version them, don't release them.
>
> Ok, that's a good alternative, but how can you remenber on what you were
> working yesterday?
I don't need to remember them. The system highlights them for me. VAJ
provides great query tools that you can use to get a quick list of all of
your open editions.
> Did you modify that file on purpose? Do you have to check
> it in in order for the whole system to work?
Not too different from the questions you need to ask yourself when using
CVS.
> > > We haven't released anything yet
Do you mean that you are versioning classes and never releasing any of them?
Gulp! I think I am beginning to understand the magnitude of your problem.
Depending on how you want to handle class ownership in ENVY, the version and
release processes should be nearly simultaneous. You certainly shouldn't go
very long before releasing versions into the open edition of your package
and project.
-Eric
Guillermo Schwarz
I've seen people have problems with CVS also, just because they do not
understand the concepts and procedures (what to do in case of the events
that may happen). For example they do not understand that they need to
verify the repository. They think of the repository as a backup, so why
would you need to verify it? Even if they use the verification tool, they do
not understand, they think they just need to "code". Problems in the
repository? That can be solved by coding again. ;-)
I feel simmilarly lost and I do not want to spend too much time solving
these issues.
One thing that is clear is that instead of check-out and check-in, in ENVY
you just modify and version, respectively. In CVS, you can do the same if
you check-out once and then just modify and check-in. But from time to time
it is recommended to "update", which is the ENVY equivalent called "replace
with another version", but since there is no build number equivalent, it
becomes hard, or messy, depending of how much time you wish to dedicate to
the "update".
The good and the bad of ENVY:
Good things first:
1. The ">" indicating you are not working with the released version. That's
something CVS is lacking.
Bad things next:
1. No automatic merge. In CVS, you just select "update" and the merge is
done locally. No branching occurs unless you explicitly branch, then you can
merge the branches automatically if desired.
2. If you don't look at the versioning tab, you will never realize that you
have several branches. Merging branches is impossible unless you do it
manually. Developers who do not change to the latest branches appropiately
will always make the repository unstable.
3. Continuous integration is a manual procedure instead of an automatic one.
The lack of the status of the compilation of the whole project is the main
difficulty I see. If I can do that, then running the tests should not be a
problem, just hook into the project verification process. I need to find it
first though.
Cheers,
Guillermo.
"Alan Knight" <kni...@acm.org> escribió en el mensaje
news:Xns941F88F66E0...@66.185.95.104...
geoff
for releasing the right class. You make all the changes you want in your
image, version the classes, then notify the owners of the classes with the
version numbers. The owner is repsonsible for integrating code and
releasing it to everyone.
I saw Eric's reply about making envy feel more like cvs. That is like
asking how can I make my car not as nice. However, I think someone
mentioned here there are groups who can not use Envy, it seems to be too
difficult for them to understand. I noticed in the same day after reading
that, I went to Mcdonalds and the person in front of me had trouble
understanding how to use the drive up window. After 5 minutes of holding up
the line, she parked her car and went inside.
-g
"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in message
news:3f9b...@news.totallyobjects.com...
Sascha D?rdelmann
> It is interesting how you did it, but there are so many loose ends.
Ok, I've read the other answers. Some were blaiming you, assuming that
you did not understand the way Envy wants you to do something. I
assume you did read the Envy manual. I went through the manual many
times and I still don't like the 'Envy way' of continous integration.
I think, Envy is much better than most configuration management tools.
But this doesn't mean it can't learn anything from cvs, subversion or
other CM tools.
> In our case, a developer finishes a task, what did him modify? Envy doesn't
> tell you.
Envy stores version comments. We made Envy open an edit control in the
step of versioning applications just as cvs frontends like Lincvs do.
And we added a log history view.
Most developers added small hints in the version name. We didn't want
that for the configuration maps, so we decided that the first word of
the version comment of a map could just be displayed as if it was part
of the version.
We created means to work on sets of classes, methods or applications.
I'll give you one example: We made a subclass of the Application
Manager which worked on subsets of all applications and added ways to
open different kinds of such subsets (e. g. all open editions, all
apps of a certain config map, apps taken from a list of names in a
file,...).
> In our case the projects are huge mostly because we are more than
> 10 developers, there are other teams and the legacy code is huge, so finding
> what I modified is a daunting task. If I do not inform other developers,
> they will probably never know, because Envy doesn't have AFAIK something
> like CVS update.
A configuration map shows you, which applications are loaded and which
are not. If you only release versioned applications, the open editions
are yours, the one without a star are either yours or changed by
others. You could add comfort there but we never needed more than
that.
I think some other team had a selfmade tool for all this release
stuff, but I've never had a closer look because we were satisfied with
our way of doing things.
> Besides by default Envy branches each class if you don't start with the last
> class version. This reminds me the subversion designers decided that "every
> tag is a branch tag", because it becomes hellish. It is really annoying that
> you have to remember to update each class before touching it. Besides there
> is no "uncheckout" command, so you must check it in aas "bad" or something
> like that. Besides there is no automatic merge like in CVS, and that means
> that sometimes a developer overwrites what somebody else has done. That's
> not pretty. Maybe the "savely relese" would help, what did it do? Maybe I
> can reproduce it. I have yet to understand how to create something like
> that.
Our 'savely release' checked if the previous edition of the
application you'd like to release is the one which is currently
released in the configuration map. This works fine if you don't
version without release. You could modify it to check user names, too.
Manual merge has some advantages, too. You have much more control over
the changes. I always made merges an additional step. In fact I did
only merge versions and never open editions. (Note: 'savely release'
won't work after such a step.) Doing so, I was able to reproduce
errors in the merge itself by comparing the different versions.
I know developers who don't trust automatic merges. Envy is very well
suited for them. And Envy is great at comparing large amounts of
sourcecode like complete configuration maps. We only added a small
tool to compare different maps not just different editons of one map.
> Besides how can you tag the whole project to produce a build? I think Envy
> can't.
Version the configuration map. Take a clean base image and load the
map into it. If that works, you're done. There is a little problem
with the regression testing because you have to load the testing
framework and can't be sure that the tested applications don't use
extensions made by the framework or by the IDE. I think, you should
use a lint tool to check things like that.
The main problem with most of my suggestions is that you create a
tailored Envy version which none of the new team members will know at
first.
Cheers
Sascha
Guillermo Schwarz
"Eric Clayberg" <clay...@instantiations.com> escribió en el mensaje
news:sRHmb.3281$X22....@newsread2.news.atl.earthlink.net...
> "Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in
message
> news:3f9b...@news.totallyobjects.com...
equivalent]
>
> > but no developer is required to get up to date
> > before releasing their stuff, as they are required on CVS
>
> How does CVS *require* you to get up to date?
Get version 1.1 of a class. Other developer modifies the class on another
machine and commits into version 1.2. You modify the same class and try
commit: "Commit failed, you should update first". CVS doesn't let you
overwrite, it requires that you update and update does a merge locally on
your hard drive.
> I can easily commit a change
> to CVS that is based on an older (wrong) version of a class.
You can do that on purpose if you:
1. Update to the latest version.
2. Replace the new source with the old source. (Notice: Asking CVS to do
this for you won't work).
3. Commit.
You can't do that "by mistake".
>
> > so it is easy in ENVY to get versions messed up
>
> The only way to get things "messed up" is to misuse the system. ENVY has
its
> rules just like CVS does. Each requires its own unique process, and, if
you
> try to force one mindset onto the other, you will be very disappointed.
When
> I first started using CVS (after ten years of using ENVY), I was very
> disappointed at how light weight it was relative to ENVY. I have gotten
use
> to it, and have no problem using it, but I do miss using ENVY on a daily
> basis.
That's exactly what I was expecting of ENVY, since I had read in this ng and
on others how good it was.
My fellow developers have the same problem with the VA4J environment since
they have never used Smalltalk, they find the environment cumbersome. I feel
really comfortable with the environment, while they prefer to use another
editor and then copy/paste into VA4J.
>
> > > Ummm, if you don't want the "bad" edition, just leave them as
> > > open-editions - don't version them, don't release them.
> >
> > Ok, that's a good alternative, but how can you remenber on what you were
> > working yesterday?
>
> I don't need to remember them. The system highlights them for me. VAJ
> provides great query tools that you can use to get a quick list of all of
> your open editions.
Do I have to program them or they are just a menu away?
>
> > Did you modify that file on purpose? Do you have to check
> > it in in order for the whole system to work?
>
> Not too different from the questions you need to ask yourself when using
> CVS.
Yes, that's why I use a tool similar to CruiseControl for verifying the
repository and I update an issue in ITracker or something simmilar to
remember what was modified when and why. The difference is that using
TortoiseCVS it tells me what files I did modify in my local computer, I see
no simmilar in ENVY.
>
> > > > We haven't released anything yet
>
> Do you mean that you are versioning classes and never releasing any of
them?
No, I meant release to the customer. We are supposed to release classes
every time we finish a task, that's simmilar to CVS commit, but there are
many open editions, the tree becomes huge and when several developers are
modifying the same class, it is not easy.
> Gulp! I think I am beginning to understand the magnitude of your problem.
> Depending on how you want to handle class ownership in ENVY, the version
and
> release processes should be nearly simultaneous. You certainly shouldn't
go
> very long before releasing versions into the open edition of your package
> and project.
Ok, maybe telling ENVY to update to the latest release every time it starts
up should solve most of the problems. Then releasing often (that sounds
similar to an XP practice ;-) should solve the other half. The problem I
have with "replace with release contents" is that it doesn't merge my
changes with the released version, but simply replaces my code.
Thanks,
Guillermo Schwarz.
>
> -Eric
>
>
Guillermo Schwarz
Asking the owner to release the class is cumbersome to say the least. I
think XP talks you out of that when it encourages "Collective ownership".
Cheers,
Guillermo Schwarz.
"geoff" <nos...@nospam.org> escribió en el mensaje
news:xoJmb.3339$X22...@newsread2.news.atl.earthlink.net...
geoff
Sorry you feel that way because the whole point of doing it like that is to
get a people on a team to talk to each other. Maybe it is cumbersome to you
but my company keeps project statistics and so far, ST and Envy has beaten
out everyone else to the point that we are getting knew projects.
> . . . into CVS and doing things right.
I re-read some of what you wrote and realized this is coming from not
understanding how it works and probably never using it before. In your
other note, you wrote:
> In our case, a developer finishes a task, what did him modify?
When you are done making changes, you can query for open editions or
unreleased classes.
> If I do not inform other developers, they will probably never
> know, because Envy doesn't have AFAIK something like CVS
> update.
Query for open editions or unreleased classes and send the list to the
appropriate owners. Class/app/config map owners make sure the proper
classes/apps are released. When the latest config map is loaded, developers
get everything. However, it is not always necessary to do that unless
developers are stepping on each others toes. Im which case, you have
management issues.
> Yes, I am. Let us suppose developer 1 generates version 1, 2 and 3 of
class
> A and version 2 of class B. Then developer 2 generates version 4 of class
A,
> version 3 of class B and version 5 of class C.
>
> How do I know which versions should I use if I want to develop something?
> Should I browse ENVY to see who has modified what? That would be very time
> consuming. There is no way to get up to date without asking every
developer
> what have they modified.
Developers should be in the habit of loading the latest config map before
making changes and if class owners are doing their job then when you load
the latest config map, you would get the changes others made. If you are
working on a class that you do not own then it is not your job to integrate
code, etc. and get the right class released.
> Yes, released versions, but no developer is required to get up to date
> before releasing their stuff, as they are required on CVS, so it is easy
in
> ENVY to get versions messed up (individual classes are ok, but the whole
> doesn't work).
Each developer should be loading the latest config map before working.
Class owners make sure classes work, app owners make sure apps work, and the
config map owners work at the config map level.
> Ok, that's a good alternative, but how can you remenber on what you were
> working yesterday? Did you modify that file on purpose? Do you have to
check
> it in in order for the whole system to work?
Either save your image or query for open editions and load those classes
when you come into work the next day.
Envy has been working well for smalltalk for a long time. The 'cvs is
better' thing is not going to trash the years success envy has had and
continues to have. If you like cvs then I am sure there are plenty of
projects that use it. My greatest productivity started when I switched to
envy 10 years ago and never had a problem with it.
-g
Eric Clayberg
>
> > How does CVS *require* you to get up to date?
>
> Get version 1.1 of a class. Other developer modifies the class on another
> machine and commits into version 1.2. You modify the same class and try
> commit: "Commit failed, you should update first". CVS doesn't let you
> overwrite, it requires that you update and update does a merge locally on
> your hard drive.
That behavior must depend on how you have CVS configured. We are using CVS
with Eclipse and it doesn't do that. You can easily overwrite changes
without updating first.
> You can do that on purpose if you:
>
> 1. Update to the latest version.
> 2. Replace the new source with the old source. (Notice: Asking CVS to do
> this for you won't work).
> 3. Commit.
No. All I need to do is commit and tell it to ignore any conflict warnings.
> > I don't need to remember them. The system highlights them for me. VAJ
> > provides great query tools that you can use to get a quick list of all
of
> > your open editions.
>
> Do I have to program them or they are just a menu away?
They are built right in. Just select the "Management Query" command from the
"Workspace" menu. If you have VA Assist loaded
(http://www.instantiations.com/assist), it doubles the number of available
queries
(http://www.instantiations.com/assist/docs/envy_management_query.htm) and
adds a "Repository Query" command as well
(http://www.instantiations.com/assist/docs/envy_repository_query.htm).
> The difference is that using TortoiseCVS it tells me what files I did
modify
> in my local computer, I see no simmilar in ENVY.
ENVY can tell you that very easily in either Smalltalk or Java. Just use the
Management Query tool for a list of "Open Editions" or "Unreleased"
versions.
> No, I meant release to the customer. We are supposed to release classes
> every time we finish a task, that's simmilar to CVS commit, but there are
> many open editions, the tree becomes huge and when several developers are
> modifying the same class, it is not easy.
If multiple developers are modifying the *same* class at the same time, it's
not very easy in CVS either. Ideally, you should avoid having multiple
developers working on exactly the same code. IOW, if one developer has
already created an open edition of a class, don't create any additional open
editions until the current edition has been versioned and released. You can
merge two derived versions together if you need to, but is best to avoid the
issue from the beginning. I think that applied to both ENVY and CVS.
> Ok, maybe telling ENVY to update to the latest release every time it
starts
> up should solve most of the problems. Then releasing often (that sounds
> similar to an XP practice ;-) should solve the other half.
I would think so.
> The problem I have with "replace with release contents" is that it doesn't
> merge my changes with the released version, but simply replaces my code.
If you release your changes first, then replacing with the release contents
won't replace your code at all. Before you reload the open edition of your
project or package, you should always release your changes first. Until you
release them, they aren't committed (from a CVS point of view).You would
have the same problem in CVS if you told it to load the current contents of
the HEAD stream without first committing your changes.
Sascha D?rdelmann
> > Asking the owner to release the class is cumbersome to say the least.
>
> Sorry you feel that way because the whole point of doing it like that is to
> get a people on a team to talk to each other.
The problem with asking the class owner to release a class into an
application in not only a communication problem. If my work involves
10 classes I'll have to ask up to 10 people to get my work into the
rolling baseline. How can I be sure that they all release my changes
immediately. That's what continuous integration is all about: Giving
developers the opportunity to take care for the integrity of the
baseline.
> > If I do not inform other developers, they will probably never
> > know, because Envy doesn't have AFAIK something like CVS
> > update.
>
> Query for open editions or unreleased classes and send the list to the
> appropriate owners. Class/app/config map owners make sure the proper
> classes/apps are released. When the latest config map is loaded, developers
> get everything.
Again, this procedure does not guarantee integrity of the baseline.
> However, it is not always necessary to do that unless
> developers are stepping on each others toes. Im which case, you have
> management issues.
Even if it's a management or design issue: I don't want a tool to
decide that for me.
What I would like to see is the possibility to propagate/release
versioned change-sets into a rolling baseline. Neither Envy nor CVS
work like this, but most CVS frontends do and you can use Envy in
similar ways without giving up most of the advantages of Envy.
Cheers
Sascha
geoff
> application in not only a communication problem. If my work involves
> 10 classes I'll have to ask up to 10 people to get my work into the
> rolling baseline. How can I be sure that they all release my changes
> immediately. That's what continuous integration is all about: Giving
> developers the opportunity to take care for the integrity of the
> baseline.
Communication is what Envy is all about. Your statement suggests, 'only I
know how to do things right', and the rest of the app and class owners do
not. If you work on teams that do no like to communicate then you are
right, you shouldn't use envy.
I have had changes like the ones you describe where they have to be released
at the same time. I would talk to the config map owner and ask what he
wants to do or how he wants to handle it. After he decides, I may or may
not be involved but he has the list of changed classes and apps affected
because I did a query on my image.
I have not had the problems you describe. However, I can easily see the
problems being described in this thread popping up a lot if people have the
attitude that cvs does it right and envy does not or 'I do not like talking
to other team members'.
-g
"Sascha D?rdelmann" <ws...@onlinehome.de> wrote in message
news:a39cf4fe.03102...@posting.google.com...
Jochen Riekhof
scanning this thread, and reading a bit in the VisualWorks docs about STore,
I get the (very vague) impression that Envy and Store are quite similar in
usage, but different from the SCMs for C++/Java I know.
As I like the idea of having kind of a "module" owner who controls
the release process (at least for parts of the codebase) I also wonder if
there are SCM systems for Java/C++ out there that support this.
Any info would be appreciated
Ciao
...Jochen
Isaac Gouy
> > The problem with asking the class owner to release a class into an
> > application in not only a communication problem. If my work involves
> > 10 classes I'll have to ask up to 10 people to get my work into the
> > rolling baseline. How can I be sure that they all release my changes
> > immediately. That's what continuous integration is all about: Giving
> > developers the opportunity to take care for the integrity of the
> > baseline.
>
> Communication is what Envy is all about. Your statement suggests, 'only I
> know how to do things right', and the rest of the app and class owners do
> not. If you work on teams that do no like to communicate then you are
> right, you shouldn't use envy.
It is possible to use Envy successfully without adopting the strong
class ownership process described in the Envy manuals ;-)
(It isn't possible to use any shared code repository successfully
without a willingness to identify and resolve conflicting changes.)
Sascha D?rdelmann
> Communication is what Envy is all about. Your statement suggests, 'only I
> know how to do things right', and the rest of the app and class owners do
> not. If you work on teams that do no like to communicate then you are
> right, you shouldn't use envy.
I think you misunderstood my argument, it's not about knowledge it's
purly technical. Only one person has one set of related changes at his
fingertips. He is not the one who knows everything. He is the one who
can easily run the regression tests on the hypothetic new baseline
(old baseline plus his changes) befor releasing the stuff.
The others may trust him or not that he has done a good job on the
task he was resposible for, that's not the point. They have the
responsibility to check parts of the changes which interfere with
their own work, I totally agree with you there. What I say is that he
should be able to release it because otherways it's difficult to
release all the changes at once. Asking people to release parts of the
change won't help you there.
> I have had changes like the ones you describe where they have to be released
> at the same time. I would talk to the config map owner and ask what he
> wants to do or how he wants to handle it. After he decides, I may or may
> not be involved but he has the list of changed classes and apps affected
> because I did a query on my image.
How did he manage to release everything at once, then?
> I have not had the problems you describe.
No problems, we just didn't do things in the way the Envy manual
wanted us to do ;-)
Cheers
Sascha
Guillermo Schwarz
> > Asking the owner to release the class is cumbersome to say the least.
>
> Sorry you feel that way because the whole point of doing it like that is
to
> get a people on a team to talk to each other. Maybe it is cumbersome to
you
> but my company keeps project statistics and so far, ST and Envy has beaten
> out everyone else to the point that we are getting knew projects.
Good point, but I would attribute that more to ST than Envy. I might be
wrong though.
>
>
> > . . . into CVS and doing things right.
>
> I re-read some of what you wrote and realized this is coming from not
> understanding how it works and probably never using it before.
I agree. It may be that or it may be that I was expecting to have similar
tools as in CVS or both. By the way, the version tab that shows the graph in
VA4J is so fast, I think that could never be done as fast in CVS. But that
blazing performance for that feature is not as important as other features
CVS has.
> In your
> other note, you wrote:
>
>
> > In our case, a developer finishes a task, what did him modify?
>
> When you are done making changes, you can query for open editions or
> unreleased classes.
Is there a browser for that or I have to browse manually?
>
>
> > If I do not inform other developers, they will probably never
> > know, because Envy doesn't have AFAIK something like CVS
> > update.
>
> Query for open editions or unreleased classes and send the list to the
> appropriate owners. Class/app/config map owners make sure the proper
> classes/apps are released. When the latest config map is loaded,
developers
> get everything. However, it is not always necessary to do that unless
> developers are stepping on each others toes. Im which case, you have
> management issues.
Which naturally you don't have in CVS. In CVS everyone can modify
everything. You have to take care of tests (removing a test is a dangerous
operation), besides that, I do not see a problem letting developers modify
everything as they see fit.
The problems I have with release owners is:
1. It contradicts collective ownership.
2. How do they know that what they are relasing is the correct stuff. Please
note that in practice a versioned class should be released immediatly, so
there are potencially several releasers, who knows that the release is ok?
Do you have to manually test everything to be sure? If you don't have ant or
the like, how do verify everything compiles and everything passes the tests?
Do you expect someone to be sitting all day in front of a computer doing
that?
>
>
> > Yes, I am. Let us suppose developer 1 generates version 1, 2 and 3 of
> class
> > A and version 2 of class B. Then developer 2 generates version 4 of
class
> A,
> > version 3 of class B and version 5 of class C.
> >
> > How do I know which versions should I use if I want to develop
something?
> > Should I browse ENVY to see who has modified what? That would be very
time
> > consuming. There is no way to get up to date without asking every
> developer
> > what have they modified.
>
> Developers should be in the habit of loading the latest config map before
> making changes and if class owners are doing their job then when you load
> the latest config map, you would get the changes others made. If you are
> working on a class that you do not own then it is not your job to
integrate
> code, etc. and get the right class released.
Ok, so class owners are integrators. Integration is a difficult task and it
is important enough to put mature developers to do it, but it is extremely
boring. I think CVS wins hands down in that one.
>
>
> > Yes, released versions, but no developer is required to get up to date
> > before releasing their stuff, as they are required on CVS, so it is easy
> in
> > ENVY to get versions messed up (individual classes are ok, but the whole
> > doesn't work).
>
> Each developer should be loading the latest config map before working.
Sure if he versions/releases the class in a few minutes or a few hours, that
would work. But developers sometimes take days. In SourceSafe you can lock
files for days and nobody can modify them while you work on them. The same
is true for CCC/Harvest. I would not recomend those tools if you can use
CVS, because CVS merges the files automatically. If there are "conflicts"
(same lines modified by 2 different developers), then CVS doesn't merge
those lines, but put some markers in the file explaining what code was there
before, what is in the repository and what is there locally. The semi-merged
file stays in the local system until all conflicts are solved manually.
> Class owners make sure classes work, app owners make sure apps work, and
the
> config map owners work at the config map level.
Yes, that makes sense. Now what if dev A writes class A that uses class B.
Dev B writes class B that inherits from class A. Both are in version 1.1 and
everything works. Independently they make changes on their classes,
everything works this way, they version/release those changes and everything
stop working. None of them realized, because they are not required to run
anything from the repository after version/release. Other developers
"replace with released version" and they get a mess, but they don't know
because they are not required to run anything over the code they just got
from the repository. Like this a bug can go undetected for months.
>
>
> > Ok, that's a good alternative, but how can you remenber on what you were
> > working yesterday? Did you modify that file on purpose? Do you have to
> check
> > it in in order for the whole system to work?
>
> Either save your image or query for open editions and load those classes
> when you come into work the next day.
That sounds nice. How can I query for open editions? Is that a menu away?
>
>
> Envy has been working well for smalltalk for a long time. The 'cvs is
> better' thing is not going to trash the years success envy has had and
> continues to have.
I suppose. Maybe CVS is better, but if you are already used to Envy it is
hard to see any advantage in CVS. Actually if you use Smalltalk, CVS is a
problem, because CVS doesn't see classes, it sees files, so making them work
together would probably be hard. That doesn't mean that probably there are
one or two things out there that Envy could not benefit from.
I'm not saying that CVS is perfect either. It is far from perfect. It is
really cumbersome and erro prone if you don't use TortoiseCVS as a client,
and even in that case sometimes it doesn't do what you expect.
> If you like cvs then I am sure there are plenty of
> projects that use it.
Yes, I could probably migrate to another project. But for some reason big
companies prefer products with support...
> My greatest productivity started when I switched to
> envy 10 years ago and never had a problem with it.
>
> -g
That's exactly what I would like to achieve. Excuse me if it looked like I
was trying to bash Envy or the like. I was just a little frustrated by my
inability to work as expected.
Guillermo Schwarz
> "Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote:
> > It is interesting how you did it, but there are so many loose ends.
>
> Ok, I've read the other answers. Some were blaiming you, assuming that
> you did not understand the way Envy wants you to do something. I
> assume you did read the Envy manual.
No I didn't. I live and work in Chile, here resources are very scarce.
> I went through the manual many
> times and I still don't like the 'Envy way' of continous integration.
> I think, Envy is much better than most configuration management tools.
> But this doesn't mean it can't learn anything from cvs, subversion or
> other CM tools.
>
> > In our case, a developer finishes a task, what did him modify? Envy
doesn't
> > tell you.
>
> Envy stores version comments.
I do not know where. In CVS when you commit you can enter a text. The
version numbers are automatically determined by CVS. In Envy, you can't
enter a thing when you release. When you version you can either enter a
number or a comment. You can also enter "4.5.6 this solves the foo bar
problem", but it is not consistent with what other developers enter.
> We made Envy open an edit control in the
> step of versioning applications just as cvs frontends like Lincvs do.
> And we added a log history view.
You did that in Smalltalk, right?
>
> Most developers added small hints in the version name. We didn't want
> that for the configuration maps, so we decided that the first word of
> the version comment of a map could just be displayed as if it was part
> of the version.
>
> We created means to work on sets of classes, methods or applications.
> I'll give you one example: We made a subclass of the Application
> Manager which worked on subsets of all applications and added ways to
> open different kinds of such subsets (e. g. all open editions, all
> apps of a certain config map, apps taken from a list of names in a
> file,...).
That sounds interesting, maybe that could help me determine what do I have
to release in my image, right?
>
> > In our case the projects are huge mostly because we are more than
> > 10 developers, there are other teams and the legacy code is huge, so
finding
> > what I modified is a daunting task. If I do not inform other developers,
> > they will probably never know, because Envy doesn't have AFAIK something
> > like CVS update.
>
> A configuration map shows you, which applications are loaded and which
> are not. If you only release versioned applications, the open editions
> are yours, the one without a star are either yours or changed by
> others. You could add comfort there but we never needed more than
> that.
>
> I think some other team had a selfmade tool for all this release
> stuff, but I've never had a closer look because we were satisfied with
> our way of doing things.
I learned CVS by using it in large groups and doing things as was indicated
by the team leader. Over time I became a team leader and indicated other
people what the process was. Then the process could be refined. Now I'm
starting from zero and it seems that most Envy developers use custom made
tools, despite that "Envy is the best version control software". Maybe it is
the best because it lets you modify it and create tools using Smalltalk.
What if I want to follow the CVS way, can I write my own tools to let Envy
behave like CVS? I know there will be some differences, but at least I want
Envy to merge files (classes?) automatically.
If there is a problem in the merge process and the merge process itself
doesn't realize, either it won't compile or it won't pass the tests. The
worst thing that could happen is that a test gets removed by accident, I
would manually diff the merged test to see if I lost something, but besides
that, I see no reason to manually merge.
>
> I know developers who don't trust automatic merges. Envy is very well
> suited for them. And Envy is great at comparing large amounts of
> sourcecode like complete configuration maps. We only added a small
> tool to compare different maps not just different editons of one map.
It looks like you wrote a lot of Smalltalk code, am I right?
>
> > Besides how can you tag the whole project to produce a build? I think
Envy
> > can't.
>
> Version the configuration map. Take a clean base image and load the
> map into it. If that works, you're done. There is a little problem
> with the regression testing because you have to load the testing
> framework and can't be sure that the tested applications don't use
> extensions made by the framework or by the IDE. I think, you should
> use a lint tool to check things like that.
Sure I can version and then open a new edition so that developers can
continue working. Can I do that several times a day? Is that as simple as
pressing a button on a webpage? It took me something like a week to do that
with CVS, and the webpage is in one machine and ant runs in another. Can you
do that in Envy?
>
> The main problem with most of my suggestions is that you create a
> tailored Envy version which none of the new team members will know at
> first.
I have to modify the Envy server? I will never have those privileges. We are
working at a highly burocratic company, hell will freeze before I get to
know where that machine is.
>
> Cheers
> Sascha
Thanks for all your help,
Guillermo.
Sascha D?rdelmann
> > Envy stores version comments.
>
> I do not know where.
In the Smalltalk Envy they are called Notes. And from the number of
times I had to explain to team members where they can actually edit
them I guess they are hard to find. ;-)
> You did that in Smalltalk, right?
Yes, in VisualWorks.
> > We created means to work on sets of classes, methods or applications.
> > I'll give you one example: We made a subclass of the Application
> > Manager which worked on subsets of all applications and added ways to
> > open different kinds of such subsets (e. g. all open editions, all
> > apps of a certain config map, apps taken from a list of names in a
> > file,...).
>
> That sounds interesting, maybe that could help me determine what do I have
> to release in my image, right?
Yes, that's one of the benefits. The main purpose was to speed up
browsing and searching in general.
> I learned CVS by using it in large groups and doing things as was indicated
> by the team leader. Over time I became a team leader and indicated other
> people what the process was. Then the process could be refined. Now I'm
> starting from zero and it seems that most Envy developers use custom made
> tools, despite that "Envy is the best version control software". Maybe it is
> the best because it lets you modify it and create tools using Smalltalk.
> What if I want to follow the CVS way, can I write my own tools to let Envy
> behave like CVS? I know there will be some differences, but at least I want
> Envy to merge files (classes?) automatically.
I don't know how to do that with envy. We had a CVS-like workflow but
no automatic merge. I didn't miss it while working with Envy but I
admit that the simple mechanism of CVS works very good in practice.
> It looks like you wrote a lot of Smalltalk code, am I right?
We had some tools and a configuration process at the time when we
migrated into Envy. We then started using Envy without these tools.
After a while I added some minor convenience functions and noticed a
significant increase of speed for some of my day by day tasks. Other
developers did the same so we started to collect these tools in an
additional config map which could be loaded in addition to the usual
image. It became clear very fast that every single developer of the
team used some of these tools but nobody felt the need to use all of
them.
So this sounds like we had a lot of additional code. That's true, but
the main changes to Envy were just a few lines here and there. You
have to take in account that the Envy version for VisualWorks lacks
some features you'll get with the Java version. At least that's what
I've been told. I don't know the Java version.
> > > Besides how can you tag the whole project to produce a build?
> > > I think Envy can't.
> >
> > Version the configuration map. Take a clean base image and load the
> > map into it. If that works, you're done. There is a little problem
> > with the regression testing because you have to load the testing
> > framework and can't be sure that the tested applications don't use
> > extensions made by the framework or by the IDE. I think, you should
> > use a lint tool to check things like that.
>
> Sure I can version and then open a new edition so that developers can
> continue working. Can I do that several times a day? Is that as simple as
> pressing a button on a webpage? It took me something like a week to do that
> with CVS, and the webpage is in one machine and ant runs in another. Can you
> do that in Envy?
So, do you tag the CVS head many times a day? I don't. You could
version a config map automatically with a small script, but we only
did this for about two weeks before a release. The release steps for a
developer (application manager/class owner) require more work than
with CVS, that's true.
> > The main problem with most of my suggestions is that you create a
> > tailored Envy version which none of the new team members will know at
> > first.
>
> I have to modify the Envy server? I will never have those privileges. We are
> working at a highly burocratic company, hell will freeze before I get to
> know where that machine is.
No, of course not! As I said in one of the other posts: The only
things we touched were part of the GUI not the core system. Even in
Smalltalk the source of the core system is hidden and I strongly
recommend to don't touch it. The only thing you can do about the
server is to decide if password checking for the users is needed or
not.
Cheers,
Sascha
Joseph Pelrine
Guillermo Schwarz wrote:
>"Sascha D?rdelmann" <ws...@onlinehome.de> escribió en el mensaje
>news:a39cf4fe.03102...@posting.google.com...
>
>>"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote:
>>
>>>It is interesting how you did it, but there are so many loose ends.
>>>
>>Ok, I've read the other answers. Some were blaiming you, assuming that
>>you did not understand the way Envy wants you to do something. I
>>assume you did read the Envy manual.
>>
>
>No I didn't. I live and work in Chile, here resources are very scarce.
>
This thread is getting confusing. Many people adding their opinions, and
you don't know who to listen to and who to believe.
As someone mentioned in this thread, the term "continuous integration"
in XP was coined with ENVY in mind. It's a tight fit, but it definitely
is doable. What you need, though, is access to accurate resources for
doing this. These resources consist of books and other documentation,
training, software, and access to people who have been there and done it
successfully. At the risk of plugging things, here are some suggestions:
Books: The OTI manuals are very good, but are a bit weak in explaining
the "why" or the philosophy behind the ENVY way of doing things.
"Mastering ENVY/Developer" was written for this reason - not as a
substitute for, but rather as an addition to, the manuals.
Training: There are still a small number of companies out there offering
high quality training in ENVY. Linea Engineering probably has currently
the best open course offerings. Don't underestimate the importance of
training. Having myself seen and reviewed one project referred to in
this thread, I must say that the developers there would have profited
greatly from having had at least a beginner's course in ENVY before they
started hacking the system.
Software: There are a number of sites offering add-ons to ENVY - mainly
for Smalltalk, not that many for Java. Here, as with the opinions of the
people posting, it's difficult to know which software is good.
Without a doubt, the best add-on tool for VA (whether for Smalltalk of
Java) is VA Assist. I can't imagine developing in ENVY without it. Not
only does it cover all you need to make dealing with ENVY easier, it
also takes care of all the other annoying little tasks that pop up when
developing software using a visual composition paradigm. It's not cheap,
but it pays for itself in no time at all.
Access to people: Although a lot of knowledgeable people populate these
newsgroups, you might have better results posting your questions in
IBM's VA forums. Otherwise, listen (and *really* listen) to the people
who know their stuff. Ron Jeffries has done this - successfully - more
times than almost anyone else around. Alan Knight's post on the
conceptual differences and similarities between ENVY and CVS is
excellent and easy to understand. Eric Clayberg's posts have described
in great detail how to map ENVY concepts to CVS, if that's what you
really want to do, and theposts are so good that they should be
harvested and put up on a wiki somewhere so that others can profit from
them.
The one thing no one can do for you, though, is to teach you how ENVY
works, and (more importantly) give you the ENVY mind-set, the way of
doing things in ENVY. YOU have to use these resources to do this
yourself. If the only tool you know how to use is a hammer, all problems
look like nails. In this analogy, CVS is a hammer, ENVY a knife. If
you're gonna insist on pounding your code into submission with ENVY the
way you're used to doing it with CVS, you're gonna hurt something, and
it ain't gonna be just your finger.
BTW - If I could figure out your email address, I'd send you a copy of
the pages from "Mastering ENVY/Developer" describing the process and
what it entails. Feel free to contact me off-line for more info.
Cheers
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrin...@metaprog.com
Web: http://www.metaprog.com
"If you don't live on the edge, you're taking up too much space" -
Doug Robinson
Terry Raymond
"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in
news:3f9f...@news.totallyobjects.com:
>
> "geoff" <nos...@nospam.org> escribió en el mensaje
> news:c19nb.5961$X22....@newsread2.news.atl.earthlink.net...
>> > Asking the owner to release the class is cumbersome to say the
>> > least.
>>
>> Sorry you feel that way because the whole point of doing it like that
>> is
> to
>> get a people on a team to talk to each other. Maybe it is cumbersome
>> to
> you
>> but my company keeps project statistics and so far, ST and Envy has
>> beaten out everyone else to the point that we are getting knew
>> projects.
>
> Good point, but I would attribute that more to ST than Envy. I might
> be wrong though.
Your arguments remind me of the arguments that you see
from a C++ programmer trying to learn Smalltalk.
It is very important to keep in mind that different
programming languages have processes that are best
suited for them AND that these processes are not
necessarily suited for another language. The same
applies for code management systems.
I would recommend that you stop comparing CVS to ENVY
until you really understand the ENVY way. Once you
really understand the proper way to use ENVY then you
you can make effective comparisons between the two.
Put aside what you know about CVS and learn the processes
suited for ENVY. Joseph, Alan and Eric know ENVY very well,
pay attention to their recommendations.
--
Terry
===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk *Breakpoints* and *Watchpoints* for
80 Lazywood Ln. VW and ENVY/Developer
Tiverton, RI 02878
(401) 624-4517 traymond at craftedsmalltalk nospam dot com
http://www.craftedsmalltalk.com
===========================================================
Jay O'Connor
> I would recommend that you stop comparing CVS to ENVY until you really
> understand the ENVY way. Once you really understand the proper way to
> use ENVY then you you can make effective comparisons between the two.
FWIW I used Envy for years before ever using CVS and then I worked for a
few non-Smalltalk shops using other languages (Perl, Python, TCL) with
CVS and now I really don't like CVS at all
--
Jay O'Connor
http://www.deskofsolomon.com
- Online organizational software for teachers
Sascha D?rdelmann
> This thread is getting confusing. Many people adding their opinions, and
> you don't know who to listen to and who to believe.
Great advice! The only thing left to decide is: Who has got the best
reputation? Everything else is left to the guru and I can switch off
my brain.
;-)
Sascha
Jochen Riekhof
Joseph Pelrine
Actually, it helps if you turn on your brain first - for example, when
thinking about posting to a thread you can't contribute much to.
Cheers
--
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: jpelrin...@metaprog.com
Web: http://www.metaprog.com
"If you don't live on the edge, you're taking up too much space" -
Doug Robinson
--
Nevin Pratt
All of the people that Joseph mentioned have the "best" reputation.
They are all experts on the topic of Envy, and I don't think any of them
will venture an opinion that disagrees with another of them. If you
think you have found an item of disagreement between them, then my first
guess is that you probably misunderstoond what they said.
If you want to "switch off" everybody else except the "experts", then
listen to the individuals Joseph mentioned. And, add Joseph himself to
the list. And ignore everybody else, including me, if you want to.
Nevin
Sascha D?rdelmann
> All of the people that Joseph mentioned have the "best" reputation.
> They are all experts on the topic of Envy, and I don't think any of them
> will venture an opinion that disagrees with another of them.
Nevin, I have no problem at all with you or with the mentioned people.
If what they say have worked for them, it's totally allright for me.
I've got problems with anybody who just insults others for
questionable reasons. Just giving a hint who are the well known
experts would have been enough to make the point.
> If you
> think you have found an item of disagreement between them, then my first
> guess is that you probably misunderstoond what they said.
Yes, they all seem to promote a similar configuration management
process. A process I allready knew of. I'll answer to their posts if I
disagree and can bring a new argument into the discussion.
Cheers
Sascha
Sascha D?rdelmann
> ENVY is based around class ownership, which tends to alleviate issues of
> informing others, because class release must always go through an
> individual. This process doesn't suit everyone, and XP practice is
> usually to work as a single user.
Which would make Envy's automatic code signing mechanism useless. It
can get very hard to decide who did a certain method change. What are
the usual XP practices to cope with this?
> "Tagging the whole project" is what config maps are for. VA/Java has a
> different name for these (maybe Project?). I'm sorry you find versioning
> to cumbersome.
Just to prevent any misanderstandings: If you work on open application
editions it's not just version the config map, isn't it?
Cheers
Sascha
Sascha D?rdelmann
> 1. The ">" indicating you are not working with the released version. That's
> something CVS is lacking.
Wincvs and Lincvs both mark changed working copies. You can also use a
query update to see what would happen if you update.
Cheers
Sascha
Joseph Pelrine
>Alan Knight <kni...@acm.org> wrote:
>
>>ENVY is based around class ownership, which tends to alleviate issues of
>>informing others, because class release must always go through an
>>individual. This process doesn't suit everyone, and XP practice is
>>usually to work as a single user.
>>
>
>Which would make Envy's automatic code signing mechanism useless. It
>can get very hard to decide who did a certain method change. What are
>the usual XP practices to cope with this?
>
1. pair-programming
2. collective code ownership
Guillermo Schwarz
"Sascha D?rdelmann" <ws...@onlinehome.de> escribió en el mensaje
news:a39cf4fe.03102...@posting.google.com...
> "geoff" <nos...@nospam.org> wrote:
> > Communication is what Envy is all about. Your statement suggests, 'only
I
> > know how to do things right', and the rest of the app and class owners
do
> > not. If you work on teams that do no like to communicate then you are
> > right, you shouldn't use envy.
>
> I think you misunderstood my argument, it's not about knowledge it's
> purly technical. Only one person has one set of related changes at his
> fingertips. He is not the one who knows everything. He is the one who
> can easily run the regression tests on the hypothetic new baseline
> (old baseline plus his changes) befor releasing the stuff.
>
> The others may trust him or not that he has done a good job on the
> task he was resposible for, that's not the point. They have the
> responsibility to check parts of the changes which interfere with
> their own work, I totally agree with you there. What I say is that he
> should be able to release it because otherways it's difficult to
> release all the changes at once. Asking people to release parts of the
> change won't help you there.
That's exactly what the automated repository verification is for. If I can
automate the following:
1. Retreieve the whole project or related set of projects into a directory.
2. Tag the version I retrieved in the repository.
3. Compile the whole directory hierarchy.
4. Run the tests.
Then I can have automated repository verification. It seems Envy is not
suited for this process because of 1 and 2 are not possible, or at least not
easily identifyable.
>
> > I have had changes like the ones you describe where they have to be
released
> > at the same time. I would talk to the config map owner and ask what he
> > wants to do or how he wants to handle it. After he decides, I may or
may
> > not be involved but he has the list of changed classes and apps affected
> > because I did a query on my image.
>
> How did he manage to release everything at once, then?
And more importantly inform other developers when things were released. BTW,
shouting across the hall is not enough. ;-)
Isaac Gouy
-SNIP-
> That's exactly what the automated repository verification is for. If I can
> automate the following:
> 1. Retreieve the whole project or related set of projects into a directory.
> 2. Tag the version I retrieved in the repository.
> 3. Compile the whole directory hierarchy.
> 4. Run the tests.
>
> Then I can have automated repository verification. It seems Envy is not
> suited for this process because of 1 and 2 are not possible, or at least not
> easily identifyable.
Maybe there are a couple of different scenarios: A) automated test on
the current released code in the repository, and B) test on
un-released code versions.
What would be necessary for A?
1 get the released versions of everything (Isn't that the default?)
2 record the version identifiers (Aren't classes versioned before
release? the problem is that new versions will be released so you need
to know which were included in the test run)
...
What would be necessary for B?
1 get the released versions of everything
2 get the un-released versions for the batch of changes to be tested
(there's no representation for arbitrary changesets, so this will be
manual)
...
> > How did he manage to release everything at once, then?
>
> And more importantly inform other developers when things were released. BTW,
> shouting across the hall is not enough. ;-)
Ummmm, prepare an email that names the versions to-be-released in this
batch of changes, release the versions, send the email (or IM)
Guillermo Schwarz
are using the latest version unless you explicitly query the server, while
Envy tells you right away. Actually TortoiseCVS could be modified so that it
showed in skyblue a file that needs update, because that is something people
used to Envy miss in CVS.
Regards,
Guillermo.
"Sascha D?rdelmann" <ws...@onlinehome.de> escribió en el mensaje
news:a39cf4fe.03103...@posting.google.com...
Guillermo Schwarz
"Sascha D?rdelmann" <ws...@onlinehome.de> escribió en el mensaje
news:a39cf4fe.03102...@posting.google.com...
> > > Envy stores version comments.
> >
> > I do not know where.
>
> In the Smalltalk Envy they are called Notes. And from the number of
> times I had to explain to team members where they can actually edit
> them I guess they are hard to find. ;-)
Thanks for the tip.
...
> >
> > Sure I can version and then open a new edition so that developers can
> > continue working. Can I do that several times a day? Is that as simple
as
> > pressing a button on a webpage? It took me something like a week to do
that
> > with CVS, and the webpage is in one machine and ant runs in another. Can
you
> > do that in Envy?
>
> So, do you tag the CVS head many times a day?
Definitely. Actually I think that's exactly what continuous integration is.
If not then I have no idea what continuous integration would be good for.
> I don't. You could
> version a config map automatically with a small script, but we only
> did this for about two weeks before a release. The release steps for a
> developer (application manager/class owner) require more work than
> with CVS, that's true.
The idea of having good builds during the day is that at one point in time
it takes days to get another good build, so you can always go back to the
last known good build. There are multiple reasons for the "build break"
days, mostly that developers are incompetent, because no matter how
competent they are, they always push harder than they really can, and that's
the only way for them to realize they have pushed too hard. When that
happens they try those mistakes to go unnoticed. If there is a webpage
indicating when the last build succeded and show all those bad builds, then
their incompetence becomes public and they need to slow down to their
competent levels.
All this is asuming they write unit tests and a test break is managed as a b
uild break.
>
> > > The main problem with most of my suggestions is that you create a
> > > tailored Envy version which none of the new team members will know at
> > > first.
> >
> > I have to modify the Envy server? I will never have those privileges. We
are
> > working at a highly burocratic company, hell will freeze before I get to
> > know where that machine is.
>
> No, of course not! As I said in one of the other posts: The only
> things we touched were part of the GUI not the core system. Even in
> Smalltalk the source of the core system is hidden and I strongly
> recommend to don't touch it. The only thing you can do about the
> server is to decide if password checking for the users is needed or
> not.
Thanks probably I can do the same in Java.
>
> Cheers,
> Sascha
Regards,
Guillermo.
Guillermo Schwarz
"Isaac Gouy" <ig...@yahoo.com> escribió en el mensaje
news:ce7ef1c8.03103...@posting.google.com...
> "Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote
> -SNIP-
> > That's exactly what the automated repository verification is for. If I
can
> > automate the following:
> > 1. Retreieve the whole project or related set of projects into a
directory.
> > 2. Tag the version I retrieved in the repository.
> > 3. Compile the whole directory hierarchy.
> > 4. Run the tests.
> >
> > Then I can have automated repository verification. It seems Envy is not
> > suited for this process because of 1 and 2 are not possible, or at least
not
> > easily identifyable.
>
> Maybe there are a couple of different scenarios: A) automated test on
> the current released code in the repository, and B) test on
> un-released code versions.
>
> What would be necessary for A?
> 1 get the released versions of everything (Isn't that the default?)
Yes, I can do that manually. I can't do that in an automated way, at least
not with the knowledge I have.
> 2 record the version identifiers (Aren't classes versioned before
> release?
Yes.
> the problem is that new versions will be released so you need
> to know which were included in the test run)
Yes, I need to record those numbers. Now imagine we have integration
problems. We go and look in our database and the last known good build is
from 10 days ago. Then how can I possibly get exactly all those versions? Do
I have to manually select the versions class by class? In the project I'm
working now that would take me days, if not weeks.
> ...
>
> What would be necessary for B?
> 1 get the released versions of everything
I do not see the need for this. I can stick to the build I got from the
repository until I commit my changes back into the repository. Besides the
menu item for this is called "Replace with released version", so it erases
my changes and replaces them with whatever is in the repository. That's
inadequate.
> 2 get the un-released versions for the batch of changes to be tested
> (there's no representation for arbitrary changesets, so this will be
> manual)
Do you mean you will load those unreleased changes into another machine? I
see no need for that. The verification is done in the development machine
before release and in the integration machine after release.
> ...
>
>
> > > How did he manage to release everything at once, then?
> >
> > And more importantly inform other developers when things were released.
BTW,
> > shouting across the hall is not enough. ;-)
>
> Ummmm, prepare an email that names the versions to-be-released in this
> batch of changes, release the versions, send the email (or IM)
I do send email when I release, informing the versions, etc. That's good
when I want to take back my changes, if I can find the email I sent. That's
ok.
The problem is when there are too many files, you want to issue one command
and get all the changes at once. That's possible in CVS using build numbers
and informing those build numbers in the email. I do not see how is that
possible in Envy.
Cheers,
Guillermo Schwarz.
James A. Robertson
<guillerm...@spam.is.killing.me> wrote:
>
<snip>
>
>Yes, I need to record those numbers. Now imagine we have integration
>problems. We go and look in our database and the last known good build is
>from 10 days ago. Then how can I possibly get exactly all those versions? Do
>I have to manually select the versions class by class? In the project I'm
>working now that would take me days, if not weeks.
>> ...
>>
No. That's what Configuration maps are for - recording known
configurations.
Here's a tip. Use Envy like Envy is intended to be used, NOT the way
you would use cvs. Or turn the idea around - say I came in and
suggested that cvs was "clearly broken" because it didn't work exactly
like Envy. Would that be reasonable?
Try using Envy the way it's intended to be used for a few weeks, and
then come back with informed critiques.
>
>Cheers,
>Guillermo Schwarz.
>
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
geoff
> you would use cvs.
LOL, I find this whole thread funny because it is from people who go into it
with the idea that Envy is messed up to start with. So, I am sure if
everyone starts off with that idea then it will be true once they start
using envy.
Envy is the only the only non-file based CM I have used and my productivity
shot through the roof when I started using it.
I remember seeing someone use WebObjects from Crapple at Nortel. They had a
class browser up that looked just like the st class browser and when they
clicked on the method, the method showed up in the code pane. I wanted to
see what features web objects had, so I asked her to right mouse click in
the methods pane and browse editions of the method. It turns out the method
in the code pane was not just one method but the whole file, lol. When she
moved the scrollbar up and down, the whole file scrolled up and down.
File based CM's are like Model T's to me.
-g
Eric Clayberg
news:3fa3...@news.totallyobjects.com...
>
> > What would be necessary for A?
> > 1 get the released versions of everything (Isn't that the default?)
>
> Yes, I can do that manually. I can't do that in an automated way, at least
> not with the knowledge I have.
ENVY can be easily scripted to support a wide range of automation scenarios.
In Smalltalk, you can script it directly in Smalltalk. In Java, you can use
the VA Java Tools API to script the environment and build your own tools. In
both VA Smalltalk and VA Java, you can load VA Assist to give you access to
a much enhanced set of useful ENVY functionality. Almost everything you have
stated that you want to do with ENVY is easily doable either with ENVY out
of the box, with the assistance of VA Assist, or with a simple Smalltalk or
Java script.
> I do not see the need for this. I can stick to the build I got from the
> repository until I commit my changes back into the repository. Besides the
> menu item for this is called "Replace with released version", so it erases
> my changes and replaces them with whatever is in the repository.
If you care about your changes, you probably want to release them *before*
using "Replace with released version". If you forget to do that, you can
always loaded your changes from the repository and then release them. You
might also find that "Replace with most recent edition" and "Replace with
most recent type editions" can be very useful.
> > Ummmm, prepare an email that names the versions to-be-released in this
> > batch of changes, release the versions, send the email (or IM)
With VA Assist loaded in VAJ, you can use direct workspace to workspace
notification. You can also configure VAJ to always let you know when any new
edition have been created (and even have them automatically loaded into your
workspace). There is no reason to ever be working with out of date code in
your workspace or to *unintentionally* create more than one current open
edition of any class.
> The problem is when there are too many files, you want to issue one
command
> and get all the changes at once. That's possible in CVS using build
numbers
> and informing those build numbers in the email. I do not see how is that
> possible in Envy.
If you have need to always go back to some specific build, then you should
be versioning your project every time you build it. That way, you can
associate a specific project version with your successful build and reload
that version any time that you like.
-Eric Clayberg
Sr. Vice President of Product Development
Instantiations, Inc.
http://www.instantiations.com
http://www.instantiations.com/assist/
http://www.instantiations.com/sts
Jay O'Connor
> File based CM's are like Model T's to me.
I've been railing for awhile, to anyone that would listen, that using
files for code storage is archaic
When we write code, we deal with classes, methods, algorithms, etc..
It's very odd then to take those artifacts and try to work them into
something that makes sense on a disk. Languages are full of rules that
determine how code is arranged in files and as far as I can tell, that
should matter not one whit to the how the code actually executes, so time
spent determining how to assign code to files is time wasted
We write code in terms of classes and methods, we should manage code in
term,s of classes and methods and let the dev tools determine where that
physically resides.
--
Jay O'Connor
http://www.cybermesa.com/~joconnor/r4hsoftware
- Custom web and application software
Isaac Gouy
> I can't do that in an automated way, at least
> not with the knowledge I have.
So what are your next steps?
Eric has indicated add-in tools that seem to provide the functionality
you're looking for - how are you going to get a budget for them? You
can't get a budget so you need to build your own tools...
You mentioned that you didn't have access to documentation - how are
you going to get it?
There are only so many times that it's worth saying - I can't do X
with Envy - get the resources you need to make Envy do X!
Sascha D?rdelmann
> >Which would make Envy's automatic code signing mechanism useless. It
> >can get very hard to decide who did a certain method change. What are
> >the usual XP practices to cope with this?
> >
> 1. pair-programming
> 2. collective code ownership
What's your point? Collective code ownership and pair programming
won't lead to a state where every programmer of a big team is able to
know all of the code. So I need to know exactly who is responsible for
the part of the code I am interested in. The time I am interested in
this information and the time a piece of software has been developed
could differ months or even years.
Cheers
Sascha
c...@tric.nl
>So I need to know exactly who is responsible for
>the part of the code I am interested in.
>
completely uninteresting question...
--
Cees de Groot http://www.tric.nl <c...@tric.nl>
tric, the new way helpdesk/ticketing software, VoIP/CTI,
web applications, custom development
Guillermo Schwarz
"Eric Clayberg" <clay...@instantiations.com> escribió en el mensaje
news:1SRob.726$9M3...@newsread2.news.atl.earthlink.net...
> "Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in
message
> news:3fa3...@news.totallyobjects.com...
> >
> > > What would be necessary for A?
> > > 1 get the released versions of everything (Isn't that the default?)
> >
> > Yes, I can do that manually. I can't do that in an automated way, at
least
> > not with the knowledge I have.
>
> ENVY can be easily scripted to support a wide range of automation
scenarios.
> In Smalltalk, you can script it directly in Smalltalk. In Java, you can
use
> the VA Java Tools API to script the environment and build your own tools.
In
> both VA Smalltalk and VA Java, you can load VA Assist to give you access
to
> a much enhanced set of useful ENVY functionality. Almost everything you
have
> stated that you want to do with ENVY is easily doable either with ENVY out
> of the box, with the assistance of VA Assist, or with a simple Smalltalk
or
> Java script.
Thank you Eric. I wonder if somebody has integrated diff/patch into ENVY,
because that's exactly how CVS does automated merges. If not, maybe I could
do it using the VA Java Tools API.
>
> > I do not see the need for this. I can stick to the build I got from the
> > repository until I commit my changes back into the repository. Besides
the
> > menu item for this is called "Replace with released version", so it
erases
> > my changes and replaces them with whatever is in the repository.
>
> If you care about your changes, you probably want to release them *before*
> using "Replace with released version".
If they are not ready, I would not release them.
> If you forget to do that, you can
> always loaded your changes from the repository and then release them.
That's exactly what is needed. The only problem I have with this is that I
need to remember that I had some changes and then reload them.
I have poor memory and besides I'm using to have several sandboxes in which
I'm doing different things. This way I can release whatever I finish first
so I do not need to release all at once at the end.
> You
> might also find that "Replace with most recent edition" and "Replace with
> most recent type editions" can be very useful.
I've never seen the last one.
>
> > > Ummmm, prepare an email that names the versions to-be-released in this
> > > batch of changes, release the versions, send the email (or IM)
>
> With VA Assist loaded in VAJ, you can use direct workspace to workspace
> notification. You can also configure VAJ to always let you know when any
new
> edition have been created (and even have them automatically loaded into
your
> workspace). There is no reason to ever be working with out of date code in
> your workspace or to *unintentionally* create more than one current open
> edition of any class.
That's ideal, but I wonder how can I run all unit tests on VAJ if there is
no ant support.
>
> > The problem is when there are too many files, you want to issue one
> command
> > and get all the changes at once. That's possible in CVS using build
> numbers
> > and informing those build numbers in the email. I do not see how is that
> > possible in Envy.
>
> If you have need to always go back to some specific build, then you should
> be versioning your project every time you build it. That way, you can
> associate a specific project version with your successful build and reload
> that version any time that you like.
So far we do version the project, but we need to open the released version
and then all developers to load that open edition of the project. That's
kind of time consuming so we that very rarely.
Thanks for your help,
Guillermo Schwarz.
Ron Jeffries
<guillerm...@spam.is.killing.me> wrote:
>> If you care about your changes, you probably want to release them *before*
>> using "Replace with released version".
>
>If they are not ready, I would not release them.
>
>> If you forget to do that, you can
>> always loaded your changes from the repository and then release them.
>
>That's exactly what is needed. The only problem I have with this is that I
>need to remember that I had some changes and then reload them.
>
>I have poor memory and besides I'm using to have several sandboxes in which
>I'm doing different things. This way I can release whatever I finish first
>so I do not need to release all at once at the end.
Programmers on an XP team release their personal code a couple of times per day.
There's not much reason for multiple sandboxes.
Why do they release that often? The Continuous Integration practice is the main
reason.
Regards,
--
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.
Guillermo Schwarz
"Ron Jeffries" <ronje...@REMOVEacm.org> escribió en el mensaje
news:p6lcqvogcr5ue3djt...@4ax.com...
> On Mon, 3 Nov 2003 08:26:03 -0300, "Guillermo Schwarz"
> <guillerm...@spam.is.killing.me> wrote:
>
> >
> >I have poor memory and besides I'm using to have several sandboxes in
which
> >I'm doing different things. This way I can release whatever I finish
first
> >so I do not need to release all at once at the end.
>
> Programmers on an XP team release their personal code a couple of times
per day.
> There's not much reason for multiple sandboxes.
Sure, that's even better. I've read the XPers release every day or simply
toss whatever they were doing and they start from scratch the next day.
I'm used to release often (release in the Envy's sense), but sometimes I get
stuck in a problem (some test is not passing for example) and do not release
for several days. I'm not completely convinced that releasing at least a day
or tossing everything away is always the right choice.
For example, sometimes I'm working on something and then something with more
priority comes up, so I simply stack the request, use another sandbox and
the frozen sandbox can be reactivated several days later.
Cheers,
Guillermo Schwarz.
Guillermo Schwarz
of spending more time and money with Envy.
Cheers,
Guillermo Schwarz.
"Isaac Gouy" <ig...@yahoo.com> escribió en el mensaje
news:ce7ef1c8.03110...@posting.google.com...
Sascha D?rdelmann
> >So I need to know exactly who is responsible for
> >the part of the code I am interested in.
> >
> Why? The whole idea of collective code ownership is to make this a
> completely uninteresting question...
Maybe the word 'responsible' was not my best choice.
Communication is an important issue in the software development
process, especially in XP. Every hint about who did something might be
useful even if he is not the only owner of the code. If I know who did
a change I might be able to ask the person some questions about it. No
information might be better than wrong information, though. So I like
the Envy idea of automatically providing information about who changed
something.
Cheers
Sascha
Eric Clayberg
>
> Thank you Eric. I wonder if somebody has integrated diff/patch into ENVY,
> because that's exactly how CVS does automated merges. If not, maybe I
could
> do it using the VA Java Tools API.
You could do that with the VA Java Tools API. It allows you to retrieve,
version and release code in the repository under program control, so you
could write a tool that does just about anything. I have seen some pretty
elaborate environments built on top of VA Java just using the Tools API.
Some folks have gone so far as to almost completely replace the VAJ browser
interface with their own custom environments and tools (extreme overkill
IMO).
> > You might also find that "Replace with most recent edition" and
> > "Replace with most recent type editions" can be very useful.
> I've never seen the last one.
http://www.instantiations.com/assist/docs/envy_replace_with.htm
http://www.instantiations.com/assist/docs/
> That's ideal, but I wonder how can I run all unit tests on VAJ if there is
> no ant support.
First of all, you don't need Ant to run unit tests. You could drive those
using a Tools API script if you wanted to. Secondly, if you did want to run
some external Ant based script, you could automate the export of your code
from VAJ to the file system and automate the execution of the Ant script.
The entire process could be manually triggered with a single menu command or
scheduled to run at some specific time or at some recurring interval.
http://www.instantiations.com/assist/docs/scheduler_window.htm
> So far we do version the project, but we need to open the released version
> and then all developers to load that open edition of the project. That's
> kind of time consuming so we that very rarely.
If the delta between the editions in your image and the editions in the new
open edition is small, loading the new project edition should be a very
quick process. You can even automate the process of detecting and loading
new open editions, so you never have to worry about not having the latest
code loaded into your workspace.
http://www.instantiations.com/assist/docs/scheduler_wizard_newer_editions.htm
http://www.instantiations.com/assist/docs/scheduler_wizard_query.htm
geoff
> the Envy idea of automatically providing information about who changed
> something.
Don't say that! I was just getting ready to switch over to cvs . . . the
people at Carleton must not have known what they were doing when they
started project Orwell.
-g
Guillermo Schwarz
"geoff" <nos...@nospam.org> escribió en el mensaje
news:oPYpb.9816$Oo4....@newsread1.news.atl.earthlink.net...
automated in CVS is to know which change belongs to which change set. To
obtain that information I ask every developer to use an issue tracker system
in which they say which versions of each files they committed. That should
be updated automatically, but I've never had the time to do it.
Why a change set is so important? Because when you add a new feature or
solve a bug you make many changes in different places. When you want to test
the functionality, you need the whole change set. If the change set
introduces a bug, for example, if the system becomes unstable, you may
decide to undo the whole change set, so having all changes related is
important.
Cheers,
Guillermo Schwarz.
geoff
-g
"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in message
news:3fa8dd77$1...@news.totallyobjects.com...
Sascha D?rdelmann
> Don't say that! I was just getting ready to switch over to cvs . . . the
> people at Carleton must not have known what they were doing when they
> started project Orwell.
Have you read my posts? I do not promote CVS. As I said before: Envy
is better than most cm tools. But why stop there? Some people react on
criticism as if CVS was a virus which infects CVS users and keep them
afraid of using Envy in a Envy like way. Things I don't like at Envy
have nothing to to with CVS. I just use CVS as a hint that other ways
of doing things work for many people. I have an Idea that Continous
does something I'd like to see in Envy and CVS (introduce tasks), but
I didn't bring Continuous into the discussion because I never used it.
Talking about things I don't like at CVS, some people seem to have had
similar ideas: Subversion introduces atomic commits which I view as a
large step towards continouus integration. But as with Continuous I
haven't used Subversion, yet.
Cheers
Sascha
Isaac Gouy
> Have you read my posts? I do not promote CVS. As I said before: Envy
> is better than most cm tools. But why stop there?
Stellation?
http://stellation.eclipse.org/
geoff
Notes and he said something did not work and showed me the class and method
list. I said to him, right mouse click on the method list and load another
edition of it. He said he can't do that, he would have to pull the whole
file or grep files.
You don't get it. You keep talking here about things that do not work at
the same level as I do. If you have a tool that works at the method and
class level then now is the time to mention it.
-g
Sascha D?rdelmann
> You don't get it. You keep talking here about things that do not work at
> the same level as I do. If you have a tool that works at the method and
> class level then now is the time to mention it.
You are right: We are talking about different things. The Envy
versioning of methods and classes is great. Has anybody said anything
against it?
Cheers
Sascha
Guillermo Schwarz
concept, just classes and methods.
When using it for Java, it is good for what it does, but it is not good for
Java specific needs. And also VAJ has this compilation mechanism that
closely resembles Smalltalk in which it always decides what is the minimum
to compile. It always gets it right, while when using ant that's not always
true, so you need to recompile whole projects. What a waste of time!
When there is a repository though, I can sleep well when the whole
repository has been compiled and all tests have been run. In order to do
that, I would need to extract the repository from Envy, you can do that
easily from VAJ but not from outside VAJ... Well, maybe I can let a computer
run VAJ and run a servlet there that will extract the repository into a
directory, then I can run an external tool (ant) to compile everything and
run the tests. However VAJ does not need a build.xml file, while ant does,
so ... what a mess. Maybe the automated compilation logic can be exported
from VAJ to generate the build.xml?
Cheers,
Guillermo.
"geoff" <nos...@nospam.org> escribió en el mensaje
news:lWeqb.11573$Oo4....@newsread1.news.atl.earthlink.net...
Guillermo Schwarz
the reply.
Thanks for the document. It explained very well the Envy way of doing
things, although it assumed some knowledge of Envy. Besides it didn't go all
the way explaining things I think I need.
For example:
1. The document says that I can version the project without actually
creating a version. Normally in Envy you freeze the project (create a
baseline) and then open it again for developers to continue work, so that
developers must reload the project. It is a little bit annoying for
developers, so this is not done often, but also taking snapshopts is
necessary for being able to go back when the code in the repository becomes
unstable. I do not remember the action name used to mark the project as
version x.xx without the need for developers to change to that edition.
Basically what it does is a branch of the project and then freezes it,
freeing developers from the burden of having to update the project after
every freeze. This is exactly what I usually do in CVS, with the difference
than in CVS I simply tag the project as "build n".
2. There is no way to automatically extract the repository into a diectory,
or at least I couldn't find that in the document. If I could do that from a
servlet, for example, then I could immediatly compile and run the unit
tests. But even if I could do that, how can I compile everything if there is
no ant support? In VAJ you simply add classes mindlessly and VAJ knows what
to recompile. Doing that using ant requires a little bit more of knowledge,
but since the IDE doesn't require most developers would consider that a
waste of time. The result is that an automated build is no longer possible,
or at least administratively hard to enforce. One solution would be to
mirror VAJ functionality by generating the build.xml all the time, but that
seems to be a big project by itself.
3. What is Configuration Map Browser?
4. The document mentions that I should synchronize in special occasions. I
think we should synchronize just before version/release (check-in), period,
and in this case it should always be to the latest build number (or latest
release). There is another scenario in which we want to retrieve specific
build numbers. Taking half change sets is always a bad idea.
Cheers,
Guillermo Schwarz.
Joseph Pelrine wrote:
So, as promised, here's what I have. I ust warn you:
- this is the draft version. I don't have a copy of the finished version in
electronic form.
- we wrote the book aiming at Smalltalk. There are a lot of similarities
here, but there are a lot of thing you can't do in VAJava because the
interface is not open.
The only pieces of advice I can give you are:
- try to understand ENVY for what it is. Don't constantly compare to CVS.
That's like comparing apples and guitars:-) If you try to use ENVY as CVS,
it won0t work. Likewise, if you try to use CVS as ENVY, it won't work.
- listen to people like Alan Knight and Eric Clayberg, [...].
- get a copy of VAAssist if you can afford it. It will make your life a lot
easier. Disclaimer: Eric, Alan and I all worked on VAAssist :-)
- get a copy of Mastering ENVY/Developer. There is a lot more info on the
philosophy behind ENVY in there.
Good luck with your work. If you have more problems, let me know, and I'll
see whether I can help. Can't promise, though. Mostly, it's up to you.
Cheers
--
Joseph Pelrine [ | ]
geoff
come to, that the CVS way of doing things is better and the envy way works
but is inferior? You seem to miss the point completely, when I work with
applications, classes, and methods, I want my version control to work at
those levels also. I DO NOT WORK AT THE FILE LEVEL! If I did work at the
file level then file based CM's would be perfect.
> . . . open it again for developers to continue work, so that
> developers must reload the project. It is a little bit annoying for
> developers, so this is not done often . . .
Huh? I am not sure what you mean by project but in envy, to load a
'project' requires a right mouse click and selecting load from the menu.
That is too much work? You work at the object level but you want your cm to
work at the file level?
> 2. There is no way to automatically extract the repository into a
diectory,
LOL, you seem to be very file/directory based. I am not sure why you are
going through this about envy or if you are being forced to use it.
However, given that you seem to feel that files are the only way to do
proper CM, why subject yourself to the pain of Envy?
> In VAJ you simply add classes mindlessly and VAJ knows what
> to recompile.
What does that mean? You want to mindlessly add classes and have some part
of your code automatically recompile?
-g
"Guillermo Schwarz" <guillerm...@spam.is.killing.me> wrote in message
news:3fb5...@news.totallyobjects.com...
geoff
Yes, many of the threads talk about CVS, how CVS does things, and one person
asked how to extract the repository out to a file/directory. All of this
implicitly says that file based CMs work better than a CM scheme that works
at the same granularity I do.
-g
"Sascha D?rdelmann" <ws...@onlinehome.de> wrote in message
news:a39cf4fe.03110...@posting.google.com...
Guillermo Schwarz
> > Has anybody said anything against it?
>
> Yes, many of the threads talk about CVS, how CVS does things, and one
person
> asked how to extract the repository out to a file/directory. All of this
> implicitly says that file based CMs work better than a CM scheme that
works
> at the same granularity I do.
I think I said that. I'm working in Java right now and whenever we need to
do a release, we need to check everything by hand on VAJ. In order to verify
everything it would be ideal to be able to extract methods into the
filesystem, but guess what, Java wraps methods in classes and those classes
live in files in the filesystem.
It is not that I want to use files, Java does.
Envy would be great if after a check-in it let me know the repostory status:
Every thing compiles, all tests pass.
Cheers,
Guillermo Schwarz.
Guillermo Schwarz
"geoff" <nos...@nospam.org> escribió en el mensaje
news:K%ktb.1609$Wy4...@newsread2.news.atl.earthlink.net...
> This is actually funny to me. I am not sure what conclusion you want us
to
> come to, that the CVS way of doing things is better and the envy way works
> but is inferior?
Rather that a conclusion, I was expecting to be laughed at and then be
redirected to the easiness of Envy. Actually that kind of happened, but I
still can't see how Envy does trivial things, for the most part I think Envy
users do not care, they just spend a lot of time for every check-in and
that's normal.
For example yesterday I learnt how to move classes from one package to
another. Basically by hand, selecting one by one, but with the help of VAJ,
which tells you where did you mess up.
> You seem to miss the point completely, when I work with
> applications, classes, and methods, I want my version control to work at
> those levels also. I DO NOT WORK AT THE FILE LEVEL! If I did work at the
> file level then file based CM's would be perfect.
I agree. I do not work at the file level, BUT who cares? What I really want
is to make sure the repository has all the classes and all the correct
versions and for that I want the following:
1. The CM must email/call/im/page me if I messed it.
2. Write a log for every check-in (sorry, version/release).
This must sound silly, but because of Envy I prefer to version "every time
something works", so that I can easily go back. At the same time, if the CM
emails me every time I version something that does not compile or that
flunked some test, then I will be horribly pissed off. So it should be
everytime I release something. Can I release a group of classes at once?
Sure, but then there is no "unique version number" to go back if the
repository is messed up.
To that respect, and without try to show any disrespect, I think Envy is
childish. And as I have said before, the novel idea that you should ask the
owner to release a class is too cumbersome, XPers do not use that at all.
>
> > . . . open it again for developers to continue work, so that
> > developers must reload the project. It is a little bit annoying for
> > developers, so this is not done often . . .
>
> Huh? I am not sure what you mean by project but in envy, to load a
> 'project' requires a right mouse click and selecting load from the menu.
> That is too much work?
Several times a day just for the sake of it, yes, absolutely. You should
automate what can be automated. I would hate driving an elevator, I'm sure
you would not love it.
> You work at the object level but you want your cm to
> work at the file level?
I see your point, but is there any importance on that? I really would prefer
a CVS working at the method level, but anyway, I never see "method versions"
anyway, so what is the real advantage?
>
>
> > 2. There is no way to automatically extract the repository into a
> diectory,
>
> LOL, you seem to be very file/directory based.
Probably. Besides Smalltalk, I see no other IDE that is not file based.
Oops, I forgot Lisp... ;-)
> I am not sure why you are
> going through this about envy or if you are being forced to use it.
Yes, I'm forced. Anyway, I had read Envy was so wonderful, and now that I'm
using it, I wonder why is it so wonderful...
> However, given that you seem to feel that files are the only way to do
> proper CM, why subject yourself to the pain of Envy?
I do not think files are the way to go. I think Envy is in the right
direction: The Smalltalk direction. I'm sure in 2023 all languages will be
object oriented, object based (instead of file based), bytecode based,
intereactive (as opossed to edit-compile-rerun-debug), blocks will be full
closures, etc. In the mean time, I just want a CM ala Aegis that does not
allow commits that turn the repository unstable, or ala Bonsai that allows
to take out the offeding commit through a trivial web based interface.
Is that too much to ask?
The reason I wanted to retrieve all the files was that I wanted to compile
everything and run all the tests, something that Envy is not prepared to do,
AFAIK.
>
>
> > In VAJ you simply add classes mindlessly and VAJ knows what
> > to recompile.
>
> What does that mean? You want to mindlessly add classes and have some
part
> of your code automatically recompile?
Does exactly what VAJ does. I enter some random code, and I do not know how,
VAJ shows me all the errors that introduces, not only in the class/method I
changed, but in others too, and it does it very rapidly.
Before working with VAJ and Wesphere Application Developer I worked with
Tomcat. The *stop tomcat/edit/compile/start tomcat/get to the page we are
testing now* cycle took at least 20 minutes. That cycle in WAD takes less
than 20 secs. WAD has this wonderful "hot-recompilation" technology that is
borrowed directly from Smalltalk, at least the idea, I do not know anything
about the implementation, probably it is JSP technology.
geoff
I do, when I want to retrieve versions of objects, merge code, etc. I want
my CM to be working at the level I do.
You remind of a guy at MCI in Atlanta. He had a phd in CS and had to use
envy to get some changes versioned. He thought it would be a no brainer to
do it but had all kinds of problems. After working with him, I found his
negativity came from a lack of understanding and nothing else.
Another guy, who works in Lotus Notes, showed me an object and the methods.
They were in a list box. I said, right mouse click on that list box and
browse editions of the selected method. His tool could not do it plus he
said, 'no one would ever want to browse editions of a method anyway'.
I am not even sure what you mean in many parts of your post but I recommend
you find another project if envy is causing you this much pain. IBM keeps
stats on the projects they run. VAJ runs about 20 function points per 100
hours, lotus notes less, but VAST consistently cranks out at 40 function
points per 100 hours. In case you were unaware of it, IBM wrote VAJ in
smalltalk initially. They knew they had to get something to market quickly,
so, they chose VAST. While they were doing the work in VAST, they told
their customers VAJ was the way to go.
I came up the ranks of assembler, motorola and intel, pascal, C, C++, and
file based CMs. All of it was inferior to ST and Envy.
-g
Guillermo Schwarz
paid for programming in Smalltalk, but certainly that would be like being
paid for being on vacation. It is a pity that the Smalltalk days are mostly
gone.
I'm really sorry about my poor English. Probably it is time to stop studying
French and get a conversation level course on English.
In regard to the part about Envy being superior to CVS, in certain respects
it is superior, but in others it feels like 20 years behind, as for example
in automated merge. I'm not saying CVS is perfect, it certainly is
cumbersome when you move a class between packages, but I find Envy to be
poor to that respect too.
The idea about having different editions of a method sounds nice, I even
have had that feature at hand for the last 3 months, but I never ever use
it, because whenever I make changes, I make those changes in multiple
places, so I want to take back all those changes at once.
In respect to the guy who has a phd in CS, well, probably the phd was not
about CM. I think it is impossible to develop software in releases and not
to have a release manager and use build numbers, probably that wasn't
mentioned in the phd either. It was hard for me at first to understand how
the whole "check-in/check-out/build number" thing worked, but I'm glad I
lerned it because it pays off.
I've worked in C++ too, those years were fun. Since I began working in Java
I remember those days as the hard days, not because of the debugging, but
because of the how awkward the language was. Java is so Smalltalk-like, but
it still tastes like C++.
BTW, Envy vs CVS is not on the list of things I look for when deciding to
move to another job. It is the continuous integration thingy that I care of.
Cheers,
Guillermo Schwarz.
"geoff" <nos...@nospam.org> escribió en el mensaje
news:23Zub.9560$Rk5....@newsread1.news.atl.earthlink.net...
Laurent Bossavit
> French and get a conversation level course on English.
My advice is to stick with French. Certainly the days of French are long
gone, but just like Smalltalk we need your help to make a comeback.
Laurent
http://bossavit.com/
Eliot Miranda
Guillermo Schwarz wrote:
> I certainly agree on the Smalltalk vs. Java comparison. I've never ever been
> paid for programming in Smalltalk, but certainly that would be like being
> paid for being on vacation. It is a pity that the Smalltalk days are mostly
> gone.
From VisualWorks' perspective the Smalltalk days are emphatically not
gone but resurgent. We've just got our year end financial results in
and have had our best year since being at Cincom. We've shown steady
growth since being with Cincom. The recent announcement of Smalltalk
jobs at JPMorganChase is an example of that growth.
Smalltalk's prospects are much better now than in the mid to late 90's
when a number of vendors' managements were panicked by Sun's marketing
of Java. VisualWorks customers are typically a) convinced that Java
cannot provide the productivity that Smalltalk can and hence skeptical
that .Net could do so, and b) confident that Cincom is solidly behind
Smalltalk (which it is).
There are now more commercial Smalltalk vendors than ever, plenty of
commercial ventures using Squeak and lots of community activity.
I hate to sound like an advert but I'm sick of negativity and lack of
confidence in Smalltalk and things really are looking up.
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
James A. Robertson
http://www.wired.com/wired/archive/11.12/billjoy.html?pg=3&topic=&topic_set=
especially this paragraph:
Will the new approach work? Hotels.com director of architecture Brad
Schneider likes the pricing scheme for the Java Enterprise System, but
his bosses are freaked out about buying from a company they think
could go under any day now. "People talk about Sun like it might have
the doors chained," he says.
Ready or not, there are outfits out there starting to wonder about the
future of Sun - which eventually will translate into worries about the
future of Java. Take it from me - once you get into that hole, it's
very, very hard to get out. It took us until year 2 or so of Cincom's
ownership of VisualWorks to get out....
On Fri, 21 Nov 2003 18:34:27 GMT, Eliot Miranda <eli...@pacbell.net>
wrote:
<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
Andre Baresel
"James A. Robertson" <jar...@gosmalltalk.com> schrieb im Newsbeitrag
news:0insrvsul9as8soab...@4ax.com...