Envy or Store or what?

Cees de Groot cg at cdegroot.com
Wed Oct 30 10:15:15 UTC 2002


 <goran.hultgren at bluefish.se> said:
>So as I understand it that puts StORE out of the race - but could
>someone in short words describe what is so cool about it?
>I have never used it.
>
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:
- flexible version numbers (I checkin a version as 'foo', StORE suggests
  'foo.1' on the following commit). No such things as machine-generated
  version numbers combined with human-readable tags. Granted, a matter of
  taste;
- code can be connected to, compared/diffed with etc, multiple repositories;
- repositories are trivial to setup: all you need is an empty supported
  database and StORE does the rest;
- graphical version browser, so you can navigate the tree, so what was merged
  into which versions, etcetera;
- integrated with (for VW7) the RB: you can see what package versions you are
  working with, whether they have been changed w.r.t. the repository, move
  classes/protocols/methods between StORE packages, see in which packages the
  code was defined and where you are overriding it, load new versions from
  StORE, ask for differences with random StORE versions, etcetera. The left
  pane of the RB, when StORE is loaded, contains StORE packages by default;
- good merge tool - you get a list of all the deltas, it automatically applies
  whatever can be applied automatically, you can then filter out the
  unresolved deltas - the conflicts - and one by one choose which version you
  want to have in the merge. The only thing that sucks here is that the
  database or the queries aren't optimized for complex merges, so that a merge
  of a multi-version branch on a trunk that's been committed to as well (so
  both branches have multiple versions since they branched) is awfully slow;
  we've seen Postgres stamping on for as much as two hours when we were stupid
  enough to leave a branch unmerged too long (it's easier to go back, file out
  the differences between the end-version on the branch and the split point,
  manually fix the chunks and file them in on the trunk).
- reasonable differences browser. Needs improvement, though. 
- optimistic locking model with automatic branching.
- hierarchical package model (code is organized in packages, packages can be
  grouped in bundles, bundles can be grouped in bundles), you can operate on
  the top level when loading and committing and StORE takes care of the rest
  on the whole tree.

I think that's basically it. 


-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo



More information about the Squeak-dev mailing list