Generally finding the switch from Visual Source Safe to SVN a boon, but there are definitely some areas where it’s weaker than you’d expect. In particular, we’re running into a few simple ball breakers:
Line Endings. Oh. My. God. When we populated the repository, we didn’t even think about this. Get this, using the Microsoft version control solution it wasn’t an issue. Ha – who’d think the first point for VSS vs Open Source RCS would be a cross-platform issue? (Anyone with coins inserted in their brain meter)
So, none of our files have svn:eol-style native. That’s the fix. But if I svn propset svn:eol-style native */*.cpp */*.h there’s just one minor itty bitty niggle: it changes every line in every file completely destroying history and blame.
I’m guessing this is because I’m using a Windows client and a Windows (VisualSVN Server) server so all the files currently (correctly) have DOS line endings, but adding the eol-style native wants to translate them to Unix style \n. I’ve tried doing this from Windows, Linux and MacOS all with the same effect – actually changing the line endings of every file in the project.
We haven’t been using the repository long so … what’s the harm?
Well, we have been using it for 4 weeks, so history is building up already, and Martini has been working off a branch – which was going great until we started running into line-ending issues. As soon as we had our first line ending inconsistency, his merge started becoming a nightmare: every time he tries to merge each file that has or has had inconsistencies stops being a diff and just becomes a whole-file conflict.
We’ve been meaning to relocate the project files to a different repository (Sebastien has been building a meta-project that includes all the 3rd party libraries, external tools, etc, which uses an svn:external reference to the WW2OL src). I guess we could just bite the bullet and lose our 4 weeks (309 revisions) of history.
Another low-ceiling that keeps banging heads is that both Tortoise SVN and VisualSVN seem to treat the local working copy as king. TortoiseSVN has “Check for Modifications” and VisualSVN has “Show Changes”. Both take you to the same dialog
Surely both are begging for a “Check for Updates” link.
Then there’s the little problem of our, uhm, unique way of organizing our project. Instead of having our project files at the top of our source tree, we have a “proj” folder alongside our “src” folder which contains platform folders for projects.
Visual Studio and XCode cope with this, but nothing really likes it. To check for modifications we have to remember to right click on the Solution not the project or VisualSVN looks below the project’s disk location and finds nothing (source is over in ..\..\src\folder). We’d probably save ourselves a lot of headache if we moved the Windows project files up to the top level — I did this with the Mac and Linux projects and life got a lot simpler for me. I guess the reason I’m not a client coder is that I’m just not enough of a masochist.
Lastly, I miss the “pending changes” feature of Visual Studio: either VisualSVN or the fact that you don’t “check out” files with SVN means that Visual Studio doesn’t recognize your changes as pending check-ins . You get visual feedback that there are changes through the little status icons so you can get the info by doing “Show Changes” but Visual Studio (with a project this big) means a lot of scrolling to find that info.
Course … The lack of a “collapse all” is one of my few Visual Studio peeves: