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