goran.hultgren@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.