We exclusively use Svn on Windows here, so while our desktops have no problems with mixed case, the Svn/Apache engine has problems with it. And since we're almost all pedigreed Windows-from-birth IT people here, we instinctively mix case to make naming conventions 'look good', not worrying about the guy (or girl) in the next cube figuring out our super-cool-but-obscure capitalization scheme on our folder structures, because 'hey, it's Windows, it doesn't really matter'.
It does matter to Subversion/Apache though, and the error messages from TortoiseSVN when you try committing changes to a folder you checked-out using the wrong case don't give you any indication that your commit hold-up is stemming from a single wrong-case character in the checked-out folder structure.
So trying to give someone some relief, I looked at the Svn roadmap for the next two years to see if they were going to fix the semi-fickleness of case in Svn/Apache (either one way or the other, I don’t care, but this in-between sucks) and unless it’s embedded in the upgrade to httpv2 they are working on (1.7, this October), there is nothing in the works. In fact, I don't see anything exciting in the works, other than shelving and checkpointing tentatively planned in Svn 1.8 for Summer of 2011.
So trying to give someone some relief, I looked at the Svn roadmap for the next two years to see if they were going to fix the semi-fickleness of case in Svn/Apache (either one way or the other, I don’t care, but this in-between sucks) and unless it’s embedded in the upgrade to httpv2 they are working on (1.7, this October), there is nothing in the works. In fact, I don't see anything exciting in the works, other than shelving and checkpointing tentatively planned in Svn 1.8 for Summer of 2011.
I looked at the major accomplishments of the prior version, version 1.6 (the version we’re on), to compare what they have done to what is in 1.7 this fall and planned for 1.8 next year, and I saw a reference to the “pack” ability for large repos. While it’s partially meant to save space, its main purpose is to eliminate the redundant tiny files that build up as revision after revision of files go in and shard after shard is created to manage the repo.
So, since we’re 100% upgraded to 1.6.x, I packed Production this morning. Space-wise we dropped ~135mb from 4.06gb, but file-wise we went from 148k files to 99k files. This should speed up disk I/O considerably, which is our current Svn speed bottleneck.
Another engineer here may move the server to the SAN later this week (!!) which would be the next performance step.
So, since we’re 100% upgraded to 1.6.x, I packed Production this morning. Space-wise we dropped ~135mb from 4.06gb, but file-wise we went from 148k files to 99k files. This should speed up disk I/O considerably, which is our current Svn speed bottleneck.
Another engineer here may move the server to the SAN later this week (!!) which would be the next performance step.
