David Weintraub wrote:
>
>In each one, we were able to build a complete development system by
>simply writing our own wrappers around an existing system. Each
>succeeding generation brought in more features that were originally
>written in our wrapper scripts because these features became to be
>understood as part and parcel of a basic version control system.
>
>So what is a basic VCS feature?
>
>
I would argue that the critical features in a version control
environment include:
- change management not just of content changes, but moves, deletes and
renames
- ability to branch the entire repository
- ability to tag, or create baseline markers
- ability to roll-back to any previous commit point
- ability to treat any set of individual changes committed at once as a
change-set
My critical features for a CM system would be:
- connecting change-sets to Change Requests (or engineering change
orders, or program amendment requests or whatever your shop calls them)
- supporting release management, i.e. some support for multiple
concurrent release branches, where each previously released branch can
only be changed by bug fixes. This is really just branch management with
a bit of workflow and documentation added.
The rest of this post I agree with.
>Maybe we can draw a parallel example with the automobile industry. In
>cars, features are divided into three groups: Basic features (you
>expect your car to have brakes), comfort features (sunroof, high end
>materials, heated seats), high end features (GPS system, high end
>sound system, multizone ac/heating system).
>
>
...
>Can you version control without true tags and branches? Well, I use to
>do version control on a system that didn't have a concept of of a
>source archive (just as a Russian friend of mine use to drive a car
>that didn't have the concept of "brakes"). All I had to do was spend
>lots of time attempting to implement the non-existent concept and then
>fixing the errors and training users to understand my front end.
>
>Today, we now spend time implementing on top of Subversion the concept
>of tags and branches. We parse the output of "svn log", we write
>hooks, we use directories, we train users in the "correct way" to do
>something, and we spend time fixing mistakes.
>
>
this is the way I see it too. It's not a criticism of svn in the sense
that I think it is 'broken'; just that it has chosen a kind of
pseudo-implementation of these important features. It's surprising the
developers bothered putting anything under the rubric 'tags' and
'branches'; in their place I would have either done nothing (svn would
still be a versioned file system) or built the semantics right in,
rather than just approximating them with existing file clone facilities.
But as I stated earlier, such features could easily belong to another
layer on the server side.
>There's a lot of great stuff in Subversion. The atomic commits, the
>flexibility of the client, the ease of installation, the open source
>nature which means I don't have to track licenses, the ability to work
>through standard Internet protocols all make Subversion an excellent
>tool. I understand Subversion is still a young tool, and new features
>are being added all the time. I also have a small list I'd like to
>see:
>
>* Tags and branches implemented as true meta-data types
>* Merging that is clean and simple (needs true branching first in order to work)
>* The ability to query files by various properties.
>* Remove old file versions. I would like to version a set of 700mb CD
>images, but that would quickly over whelm my archive storage and my
>SysAdmin's ability to do backups. It would be possible if I could
>remove the old versions of files that we no longer need, but that's
>only possible via a dump and load.
>* Remove the entire history of a file. Sometimes, a file that
>shouldn't be in the archive is accidentally added to the archive. If
>this file contains proprietary information, it must be scrubbed from
>the archive. Unfortunately, you can't remove it in Subversion.
>
>
I agree with all these (the last was possible in BitKeeper, using a
non-user friendly command, ideal for making deletion just hard enough
that only experts could do it).
>* A new type of property that is a cross between a file property and a
>revision property. I'd like to attach a property on a revision of a
>particular file. For example, to mark if that file had been
>peer-reviewed or tested by QA or whatever else I might want.
>
>
I would expect such activities to make sense across a whole baseline,
not just a single file, so I would want to be able to add such meta-data
to a named release or tag, not a file.
- thomas beale
--
___________________________________________________________________________________
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 09:12:15 2005