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.
@donaldson:
Q: Do I have the resources to manage an DB?
The answer to this can vary widely, In an engineering based company file management is easier to understand while in a computer scientist company the DB management may be easier.
But the point is with subversion, the "DB" is merely a databse *FILE*. There is no database to manage! Subversion handles all of it. In fact, any subversion database operations you have to perform are done through svnadmin, and it would be very rare that you would have to do this. Renaming files, moving directories, etc. are all handled during commits by developers. No administration is needed. There is no additional database software needed. Just a fairly standard database library that's included with almost every Linux distribution.
[quote]I was relateing an event that had occured. This event shows that DB systems are not a cure all but bring about A new set of issues and problems.
Next Question about the DB system is what happens when there is an error in the DB? ( And yes DB software has errors). For simple projects the risks of a DB may be to great.[/quote]
I never said DB systems were a cure all, I merely implied that it was better in this case. Using subversion's system is no more risky than a filesystem based one when it comes to version control systems. Especially in a "professional" environment. Since:
1) There is no database to manage, there is a database "file" and it is managed by subversion
2) All major functions such as moving, renaming, deleting, etc. are handled through the subversion client by whomever is committing changes to the repository
3) Just about any administrative functions that would have to be performed are again done by subversion (svnadmin or the client)
4) Since any professional sane company would have a daily backup of some sort of their code repositories, in the worst case scenario you may have to use your backup. If not, you can always use svnadmin recover /path/to/repository
So I really don't see how you can see it's "more risky."