Subversion 1.0.4 is a bugfix release that fixes a few problems. “svn up” can now delete unversioned data on Win32 filesystems. Memory leaks in “svnlook diff/changed/dirs-changed” were plugged. An insecure script example in the pre-commit-hook template and the inability to do a checkout to “/” were fixed.
Subversion 1.0.4 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Several of you might know me as an advocate of a certain other CMS. In order to keep from sounding like a “zealot” as I have repeatedly been accused of in the past, I will not say what it is. I will say it’s not CVS, not Subversion, and released under a copyleft free software license.
Anyway, why would anyone consider using Subversion at this point, honestly? Advocates touting its use of a ridiculous amount of overcomplexity and dependancies suggested that such a development approach would render it virtually immune from security issues and decrease the potential for bugs, yet we have just seen a fix for a security hole released and now a whole slew of bugfixes. Meanwhile Subversion provides no tier one supported method of distributed development, a basic feature of virtually every new CMS system in recent history, and the only current solution for distributed development with Subversion is a hacked together perl script which tries to cobble distributed development on top of a system which really should have been designed for it in the first place.
Subversion seems to be something of an “attention whore” in terms of next generation CMS systems, very much overhyped but insecure, buggy, and lacking in basic CMS features. I highly suggest that everyone take a look into alternatives to Subversion… there are a number of them available which don’t get nearly as much attention as they deserve.
Anyway, why would anyone consider using Subversion at this point, honestly?
In response I say honestly, how can you not understand that Arch probably suffers from similar security issues which have not been exposed as they have with Subversion because Arch’s usage is not quite as widespread.
Subversion is a production quality CVS replacement with excellent support on Windows, through well-written Explorer integrated GUI tools.
While it’s wonderful Arch has done such a good job with distributed development, the bottom line is that Arch is rather underdeveloped, undertested, and undersupported on all of its other CMS features.
> similar security issues
People should really stop writing code that interacts with foreign data in unsafe languages. -> Let’s use darcs! http://www.abridgegame.org/darcs/
Having a hard time understanding your arguments, but having
a distributed system would be nice ofcours. Then again not everyone needs that.
As for the requirements ? I couldn’t care less. It ships with
my distro, setting up a repo is a 1 minute job, works nicely
with diffrent auth methods, and pulling usernames etc. from an ldap server , which is important to me.
And, all software slightly more complicated than the average “Hello World” app will have bugs, fact of life.
If you look at the changelog for 1.0.4, it’s an amazingly small changelog though.
Because Arch is complicated and Subversion is like the familiar CVS minus some of it’s limitations plus some more features.
Arch is good for what it’s supposed to do but I don’t need that high level of decentralization right now and CVS and Subversion seem easier to learn.
I like subversion because it’s easy to understand how to use it, and it works.
I don´t see any problem with svn, I have been using it for months now and have yet to encounter a single problem. The only security flaw which has been existing was in one of the linked libs and fixed very swiftly. I am a total convert to the database based model, since I get the constant feeling that using a db as database storage increases security of filecorruption a lot, backup also is easy and secure.
The development model of svn is not flawed, neither was that in cvs, the problem with cvs was that there was no history on file level no atomic commit no real transaction mechanism which protected the files properly.
svn adresses those issues, yes distribution is nice, but for us currently unnecessary, svn is already more stable than cvs has been in its latest incarnations for us, and it is rock solid and basically flawless and easy to maintain, and also already has an excellent tool integration. Arch still has the problem of no tool integration the same basic problems of a file system storage and its documentation seems to be still a problem.
Arch will have its time but svn for me is the current choice if you want to have a serious replacment for cvs, and it indeed is.