Linked by Eugenia Loli-Queru on Fri 20th Feb 2004 06:00 UTC
On Monday, the Subversion project is scheduled to release version 1.0 of their version control system, under development for several years now. Subversion was intended from its inception as the CVS replacement and it comes with many important features previously found only on commercial VCS like Perforce. It was designed for better remote performance, and it is multi-platform with a GUI/CLI front-end.
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
"The best thing i like about CVS ... . You can easily move files around in repository, rename them or do anything"
Well you can do that, yes, if you have root access to the repository on the box where it is running (or an insecure CVS). Whilst that might be acceptable for a single person project it isn't for a networked collaberative project.
Result is that on most distributed CVS projects someone gets appointed as delegate repository hacker and spends many happy hours correcting other people's sloppy mistakes by moving directories around, renaming files, removing locks etc.
The problem with CVS is that you _have_ to hack the repository in the way you describe above to perform simple refactoring on a code base, since the command set doesn't support any other way (without loosing metadata).
Since most programmers now consider refactoring a design a normal and essential development activity, CVS is a cumbersome tool for current devopment methods - not an unworkable tool clearly, but a cumbersome one.
As for the database issue - why does it seem stupid to you? Only because you are used to working another way.
The repository is a Berkley ISAM file not some massive RDBMS. Why use it? Because implementing atomic multi-file commits on a filesystem based repository is crummy.
Besides, CVS needs the cvs commands + the repository filesystem commands to deliver a workable functionality. In SubVersion the goal is to build a secure/workable functionality from the command set itself. If you don't need to hack the repository at filesystem level why not use a record locking, rollback supporting indexed file for more efficient concurrent access?
Of course the flakey legacy of pre-NT Windows/DOS and the UNIX everything is a char stream idea makes many programmers insecure about persisting any data in formats that are not character level readable.
VMS and MVS programmers on the other hand see ISAM files as just another file type. Which systems have the better reputation for data security?
A