We have been using subversion for almost a year now. Before we did not have any regular source control schemes in place. We had tried sourcesafe but it inserts metadata into the source files to keep them in source control which was unacceptable for us. Not to mention that we could not use it outside of our network without third party tools. We have not tried cvs but I cannot see any reason to switch because of how well subversion has worked for us. On a windows machine the TortoiseSVN client is indispensable.

As far as the .svn folder issues with Visual Studio .NET web projects. We got around this problem by creating our web projects as class library projects. This solved the .svn folder issue. In addition to that, the project is not tightly linked to the particular IIS installation on that box. It allows us to open the project with Visual Studio even without IIS on the box. A huge advantage in multi user environments IMHO.

Here are a couple of links with information on how to use class library projects to make web applications.
http://pluralsight.com/wiki/default.aspx/Fritz/AspNetWithoutWebProjects2.html
http://www.peterprovost.org/archive/2003/08/15/734.aspx

Yes, Ankhsvn is a bit of a pain in the arse with VS.NET and ASPNET applications. Copying / renaming versioned files inside the project manager applet, causes grief most of the time.

However, .svn directories are clearly not what causes the problem. What is a problem is:

- You can't rename a file using the VS.NET project explorer, you have to use the Ankh option.
- If you accidentally *try* to rename a file using the PE, Ankh renames it back, but doesn't take account of the fact that it might be an aspx or ascx file with a codebehind file which also needs renaming - resulting in grief
- You can't rename a file which hasn't yet been committed - therefore VS.NET's OBSCENELY SILLY behaviour of copying things to "Copy of X", breaks things completely. If it prompted for the new name, it would be fine.

As far as I can tell, most of these problems are specific to VS.NET silly rename / copy behaviour, and/or the fact that Ankhsvn doesn't take into account codebehind files.

They are work-aroundable but annoying

---

Having used VSS, however, I can say that that is at least 99.5% less annoying than VSS, which causes your source code to be corrupted, destroys its own repository, and causes half the repository to become corrupted or deleted, on a fantastically regular basis.

Add that to the fact that VSS becomes cripplingly slow on even a modest-sized repostiory.

Plus all the stupid things that VSS doesn't let you do (i.e. anythign). And VSS doesn't correctly remember the history of deleted files!

Basically, creating backup copies on floppy discs which are fed to a baby elephant on a regular basis, then its turd examined later, is less likely to corrupt your code than using VSS.

---

If you're using VSS, why not just delete your own source code to save yourselves loads of hassle - it'll have the same end result.

Mark

Quote:Original post by paulecoyote
Yeah I know, like I said we've all lost source from source safe at one time, but I am not a manager, I'm a senior developer making recommendations and honestly migrating all our existing projects to a new source repositry would take up too much time....

Let me explain more clearly and less rant-ishly:

I have worked on several projects which used MS VSS. All of them have lost parts of the history of files at times. Many have broken down entirely and had to be thrown away.

VSS is a total non-starter as a useful source-code control system, in that it lacks the *only* useful feature of a source-code control system: the ability to actually get back old versions of your source-code!

Not only, has every VSS repository I've ever used, become corrupted to some extent, but I've spent countless hours that I would otherwise have spent developing, trying to recover broken ones (with limited degrees of success each time).

Moreover, I've spent even more countless hours, attempting to educate other developers (and sysadmin staff), how to use VSS in ways which perhaps encourage it to hold on to your sourcecode for slightly longer before breaking.

So from a manager's point of view, VSS is a very bad idea, as your senior developers end up spending time on non-development tasks, and it saps morale very badly.

I'd say, that the final negative point was, VSS's poor quality spread the message amongst the developers that source code control OF ANY TYPE, was an inherently bad idea.

It's a case of throwing the baby out with the bathwater, when developers become so pissed off with VSS, that they choose instead, to use NO SOURCE CODE CONTROL WHATSOEVER.

--

Granted, they did so because they could also see the wasted time trying to fix broken repos etc.

This is another reason why VSS should never be used for anything.

On a more positive note, perhaps we could sell copies of VSS to Iran's nuclear weapons programme scientists, in the hope that they'd lose all their data?

Mark

For what it's worth, TortoiseCVS is nearly as good as TortoiseSVN (I use both regularly, since we use SVN for internal projects, but maintain a couple of Open Soruce projects on SourceForge.net - and it is CVS only for now). So from the client point of view, you can get by with either.

I missed the other big reason we use SVN, so I figured I should post it: WebDAV support. Earlier releases of SVN only supported a small subset of WebDAV functionality, but of late it has been a pretty full-fledged WebDAV server. This means that your webmonkeys/graphic designers (many of whom are excellent at what they do, but aren't always on the same geek-scale as developers!) with Dreamweaver can view it as a remote WebDAV site, gain full version control transparently, and don't really have to understand what's going on. WebDAV is also supported by just about everything.

We actually used VSS for a while, fortunately only as a test case on some projects. It simply couldn't handle the large projects we manage (our SVN repositories add up to a few hundred gigs right now), and was really fragile. I did like its pinning feature a lot - pin a shared file in lots of projects, and updates are tracked between all copies; however, I've concluded that approach actually hurts you in the long run! We've found that we tend to get MUCH more maintainable code by building shared code into 'black box' style modules, built in a central location (with unit tests, etc.) and shared by projects as needed.

Finally, I should say that SVN isn't perfect. Earlier versions (with the BDB back-end) were known to corrupt data from time to time, although I've never had a problem that couldn't be fixed by taking the database offline and calling BDB's recovery tools. It can also be quite sluggish when you have a very large (many gigs) project checked out, particularly when updating. Oh, and Windows users need to be careful to not check Thumbs.db into the repository (TortoiseSVN makes it very easy to click "select all" in the "what to commit" box), since those get conflicted ALL the time.