When doing a project you normally have a lot of things to control
- Word docs
- Test Cases
- Data models
- Store things in lots of different files, every object or important piece of information should have its own file
- Delegate version control to an external tool
The worst thing about this is that its much easier for a tool vendor to just say "version control is done by another tool, if you want a free one then subversion is great otherwise we integrate with most of the major providers". Having this elementary dumb decisions of single files is just a very very bad design decision and completely ignores how enterprises need to manage and adopt technologies.
I really don't understand people who pitch up with a tool that fails on this basic test of
"see that individual important element in your tool, can I manage that as an individual element and do a release of that without dragging other crap in"If I'm creating a Use Case I want to version at the Use Case level, not at the repository level. If I'm creating at the Process level I want to version at the individual process level, not at the repository level. If I'm modelling a database I'd like to be able to version at the entity level not the whole schema level.
Code works like this, it would be mental to have a code versioning system that worked on every file as a clump. Yet this is what lots of packages and other tools do.
Its 2009 folks and it appears people are still building tools that can't match the capabilities of RCS let alone CVS or heaven forbid something from this millenia. So a quick summary
- Expose your things as files at the lowest level of sensible granularity, this is normally the blobs or icons in your tool
- Delegate versioning to an external product that does this stuff better. If you feel you have to include it then ship a copy of subversion.