Envy or Store or what?

Martin Kobetic kobetic at rogers.com
Wed Oct 30 16:49:01 UTC 2002


> Well, it 'sucks' in only one respect compared to ENVY - never used that, but I
> heard that ENVY writes every modification to the repository rather than to the
> changelog, which is quite great when you make mistakes. Apart from that, StORE
> offers mostly anything you want:

I think this is a matter of preference. I prefer to have control over what get's into repository and what doesn't. With ENVY if you
add and remove halt in the method 10 times you've got 20 garbage versions of the method in the repository forever. I'm much happier
for those to go into the change log and get lost when I rebuild the image next time.
I use StORE in combination with the Change Log based method-history goodie, which gives me access to all the versions that I am ever
interested to see. So I don't see this as a disadvantage, more the opposite.

> - code can be connected to, compared/diffed with etc, multiple repositories;

This is a very nice feature, which you don't get with ENVY. My development images are reconciled against 3 repositories (my local
Postgres at home (fastest), the public Postgres repo (to keep interested people in the loop), and the team repository (Oracle) in
California). Works great.

> - repositories are trivial to setup: all you need is an empty supported
>   database and StORE does the rest;

Even though a good ODBMS is possibly a better choice for a backend, I think this is a very smart choice in commercial setting.
Nobody's going to object against storing your precious source code in Oracle. And in this particular case RDBs fare well enough. One
thing I miss is having StORE sit on a good O-R mapping layer (like GLORP), to make adding your own queries easier.

> - optimistic locking model with automatic branching.

I would add that (unlike ENVY) the StORE VC model is very close to the popular update/commit model of today's file based VCs
(there's no update as such, there's load and merge instead which gives you a bit more control over the update process, and commit is
called publish). Should be much easier for new people to pick up.

It can store both the source code (just the differences), or binary (whole packages).

And finally it is the same kind of app so many developers are all too familiar with, objects stored in an RDB. Makes it quite easy
for many to get inside and customize the tool.

--
Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk




More information about the Squeak-dev mailing list