Post a Comment
We just moved our project from VSS to SVN, using vss2svn. It's phenomenal. Our productivity has increased dramatically as we're able to easily branch and merge.
Additionally it's trivial to look at a source file and find out who made a change and when (using svn blame), which helps us track down ripple bugs.
And our build process is vastly simpler. Because of the atomic operations, we don't have to warn of a build and worry that a dev might accidentally do something that will screw things up mid-build.
Also, using http and dav, we're able to give restricted permissions to a remote group, which allows them to work better and safer.
We use the excellent TortoiseSVN plugin for windows. I'll take a look at the Eclipse plugin.
Personally I prefer MS Visual SourceSafe. Why? Because it's easy to install and use.
You need a cat scan if you think SourceSafe is anywhere near the quality and ease of SourceSafe.
I spend time on programming instead of learning text commands do to anything.
TortoiseSVN in Windows Explorer and Subclipse in Eclipse. Easy to manage. There's one for Visual Studio as well.
I remember reading that SVN had bugs and I remember the recommendation was not to use it for production. I also read recently that CVS had a few bugs too. We use CVS and CVSNT but because of the better integration with Eclipse, I am tempted to push for SVN. Has anyone some information on the reliability of SVN ?
Thanks.
> Has anyone some information on the reliability of SVN ?
I use it for production, with a quite big repository and it works well. I tend to prefer using "FSFS" storage rather than Berkeley DB but both should be reliable.
Regarding bugs... Well, all software have bugs! The difference is in the way the developers handle them. And the Subversion developers seem to be responsive.
The most recent release of this is "Version 0.9.101". If they don't think it's ready for 1.*, then I wouldn't suggest using it in a production environment.
But I'm looking forward to when it's ready!
You have to realize that the version number seldom have anything to do with the quality of the software. Especially not in free software, where 1.0 often is used to represent the unattainable perfect version with no flaws whatsoever.
Just because it turns 1.0 doesn't necessarily mean that it is ready. It could be ready at 0.9.37 (the current version number of subclipse) or it could be ready at 1.01. The only way to find out if it is ready is to test it.
I remember reading that SVN had bugs and I remember the recommendation was not to use it for production.
Not true.
Has anyone some information on the reliability of SVN ?
Yes. It's absolutely fine. If you're used the the quality of something like SourceSafe then you're going to have absolutely no worries.
What's not true? Of course SVN has bugs... or "issues" as they refer to them. I haven't heard or seen any major flaws in the system recently.
http://subversion.tigris.org/project_issues.html
You may want to check out the subversion website.
http://subversion.tigris.org/
They have a lot of useful information on there, especially in their SVN book.
I wouldn't worry. Most bugs are fixed by now.
However I would reccomend using javahl instead of the pure java javaSVN in the subclipse plugin. This is much more mature, last time I checked JavaSVN had some internationalization problems.
Unfortunately javahl is a PITA to install on Unix/Linux as you usually have to build it yourself and put the .so file into $JAVA_HOME/jre/lib/i386 and the jar files into $JAVA_HOME/jre/lib/ext or make sure they are on the LD_LIBARARYPATH and the java CLASSPATH.
From what I understand, javahl is installed automagically on windows.
I have not meant svn, which is astoundingly bugfree (way less quirks than CVS) but subclipse, which still is one of the best if not the best frontends to SVN.
Anyway if you still are on CVS I really can recommend to move over to SVN, it is way better than anything CVS has to offer.



