As others have mentioned, this problem manifests itself only in VS.NET
web projects. Class libraries, windows apps, etc are unaffected by this
"bug". I followed the advice on this list and stopped using web projects
in favor of class projects for my ASP.NET development. I followed this
article
http://www.pluralsight.com/fritz/samples/aspdotnet_without_web_projects.
htm.
Incidentally, the initial reason I did this was NOT for Subversion
compatibility but for project portability. VS.NET has an extremely
annoying "feature" of not opening a web project unless the person
opening it has the EXACT same local settings (IIS path, local path, etc)
as the creator of the project. This meant that if I had a web project,
no one else could review it on their machine until they set up their
machine and project just like mine. Using class projects negates this
problem. All the other developer has to do is set the application
settings (like all ASP.NET applications) in IIS and they can put the
project wherever they want.
I did this about 9 months ago and have never looked back.
Rick
________________________________
From: Nick Bronson [mailto:Nick.Bronson@transend.com.au]
Sent: Thursday, January 13, 2005 9:06 PM
To: users@subversion.tigris.org
Subject: .Net Web Application Question
Hey everyone,
I've recently been discussing using Subversion as our primary
source control system at the company where I work and I've been given
the ok to go ahead and set it up after running some successful tests on
my local box, using TortoiseSVN as our primary access method.
I noticed in the FAQ that there can be a problem with web
applications and the .svn folder name, and I was wondering if someone
could tell me what the problem is and what causes it in a bit more
detail. It was a concern to me as we have been working on a number of
large web applications that we need source control for but I have tested
using subversion with our web apps, and publishing them from my local
dev box to the pre-production server whilst they are under source
control and there doesn't seem to be a problem at all that I can see.
I ask because it would be hard to justify using Subversion if we
have to change our workflow significantly, or use a custom version of
the clients (using _svn instead of .svn) to do it. The custom client is
out because another division in the company already uses subversion and
we need to maintain cross compatibility.
They have told me that they havn't come across any problems
either, are we missing something?
-Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 14 13:33:26 2005