Subversion case-sensitivity problems
Does anyone out there also running Subversion find this to be a little disconcerting? Stuart does. There are two issues here, first it seems there's a number of asserts in the release builds of Subversion. It appears the code uses asserts when an 'uncomfortable' state is reached - except that asserts halt/panic the server, rather than aborting the current transaction. Probably not what they intended when the started to use asserts.
The second, more acute, problem is that there's a particular assert that will occur when making a branch or tag using a mixed case string for the repository when the server expects a different case. Rephrased: If you tag a repository named http://foo/bar/trunk but you typed in http://foo/Bar/mytag then you'll bring down the entire SVN server. Nice little DoS on any SVN server, right there. The user only needs access to a single repository on that server and they can bring down the whole thing.
The bug's been reported, but I'm not seeing that it's thought of as a big deal. I hope this is fixed soon...for now, I think I'll keep my home repository on CVS. Whew.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Mark Miller
Do you have any other clients or command line SVNs like CCNET talking to the server?
Think of all the eyes that have seen this code. There is nothing wrong. There can't be. It's purely perception.
Anyway, I've also been running SVN for over a year and have never run into any problems like this. However, I use svnserve.exe and not Apache. We talk to SVN with svn.exe, TortizeSVN, AnkhSVN and Draco.NET (which uses svn.exe).
I tend to agree with Mr Miller on this, the benefits of SVN over CVS far outweigh any of the glitches we've run into. And to be honest, the only showstoppers were with the Berkley DB stuff. Modern svnserve.exe's use a FileSystem store instead of Berkley so the compatability issues are basically moot.
Since subversion is unix based, it will see Foo.txt and foo.txt as 2 different files. So if you have a developer check in foo.txt and you check in Foo.txt, you won't get a conflict.
When you try to update, though, windows see's that as the same file and TortoiseSVN freaks out. It halts the operation and you need to manually remove the bad file and merge it will the good.
Quite annoying, but in the year and a half that I have been using svn, it's only happened twice.
Ben: Case sensitivity of filenames is a separate issue (and doesn't take down the server for everyone else). Annoying, yes, but different. TortoiseSVN should do a better job, since it is a Windows-only client, but IIRC they had some clever logic to say it isn't their problem to solve.
----
[1] http://www.red-bean.com/kfogel/
[2] http://cs.ferncrk.com/blogs/stuart/archive/2006/01/22/subversion_stunning_revelations.aspx#comments
Comments are closed.