[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Using Subversion with Visual Studio .NET

From: Foy, Sean <Sean.Foy_at_TycoHealthcare.com>
Date: 2006-05-23 22:51:56 CEST

> I wanted to ask anyone out there using Subversion with Visual Studio
> .NET projects what your experiences were. Would you recommend using

My team uses VS.NET for editing and sometimes compiling code. I
started using just the commandline and TortoiseSVN, and I was happy
enough with that. When I decided to convince my team to replace VSS by
something more reliable and efficient, I started using AnkhSVN because
I knew they would want it. AnkhSVN was fine but TortoiseSVN was
improving faster and had some nice features, so these days I'm not
using Ankh. I don't see much advantage in having source
control integrated into my code editor and compiler.

> Subversion with VS.NET? Was it cumbersome? Could you integrate with

There is/was a bug in FrontPage Server Extensions, which VS.NET uses
for Web Projects, involving files that begin with a period character.
We stopped using Web Projects on my team in order to avoid having to
use non-standard SVN admin directories. If you want to use Web
Projects, then you may need a special build or to configure your SVN
client tools (Ankh, Tortoise, whatever) specially.

Fritz Onion wrote up an article that had some advice about
converting from Web Projects to ordinary Class Library projects.
http://pluralsight.com/wiki/default.aspx/Fritz/Prasanta%20kumar%20bugudai%20
Dhakan.html
That link doesn't work for me now but maybe it will be fixed soon...

On my team we have found that not using Web Projects significantly
speeds up the "open solution" operation in VS.NET, which is nice if
your company requires you to reboot often to apply security-related
hotfixes.

> merits sticking with Visual Source Safe instead?

VSS is really, really horrible. It sometimes lost data, telling us
an hour after we did a "check in" that "write failed" or something.
It is slow. It doesn't do atomic commits. It doesn't scale. It
isn't maintained (although recently MS has decided to offer an
alternative product, which they may or may not maintain). It
doesn't work well for our Unix programmers. It's hard to integrate
with other software, such as continuous integration servers or
software defect tracking systems. I could go on, but I guess I've
made the point that in my opinion, VSS has very little merit
compared to anything else I've seen. VSS's only real competition
is the practice of storing versions in directories whose name
indicates the version of the software.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 23 23:15:09 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.