RE: early reflections on subversion methodology

This is an idea I can get behind, and it's where most CM technologies
(commercial) add their value.

Everyone's got versioning - some have better technical implementations
than others (Subversion over, say VSS :P) but the real value-add is
centralized and managable workflow, development, build scheduling, etc.

Now that we have really good CM in Subversion, maybe we need a project
layer on top!

-----Original Message-----

- bottom layer: subversion as it is now (don't touch it!)
- Configuration Management semantics layer: a layer which uses the
subversion version controlled file system to store data, but adds CM
semantics, rather like BitKeeper does (it just uses SCCS files in fact,
plus a whole lot of control data, and makes it look like multiple parallel
branches all going on
- front-end (client) layer: where configuration / localisation of
workflow, process, branche types etc is done.

I guess the way I would implement the CM semantics I think should exist
would be an independent (optional) architectural layer on top of
subversion's backend.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 15:30:30 2005