[BUG] The client can't use a different directory than .svn

[Philippe Lavoie <ph...@cactus.ca>]

Hi

I've browed the archive a bit and the issue has been raised a couple of times already and I'd like to raise it again. As some of you know IIS has some quirks. One of them is that it can't cope with a file which is only an extension, i.e. .svn. 

This means that any development of a web application causes errors from Visual Studio .NET (and older versions too). This is really dumb on IIS's part, but it might never be fixed by Microsoft. Therefore, I would hope that perhaps subversion could be told to use another directory. 

Somebody said that a potential solution would be that for now, in a Windows world svn would be used and in unix .svn. That solution has the advantage of being easy to implement in the short term. Somebody also said that if somebody really cared about this, they'd generate a patch for it...

I really care about this as otherwise subversion will never be approved by our company as an 'accepted' tool. So here is a patch for this. Somepeople raised the concern that people wouldn't be able to just drop a working copy from unix onto windows, well it's true for more than just the .svn vs svn reason. The end of line character can really cause headaches when you go from one system to the other. You are better off creating a working branch and doing updates from one system to the other (my 2 cents).

Anyway, here is the patch. Inside include/svn_wc.h

At the line 692 replace 

#define SVN_WC_ADM_DIR_NAME   ".svn"

with

#ifdef _WINDOWS
	#define SVN_WC_ADM_DIR_NAME  "svn"
#else
	#define SVN_WC_ADM_DIR_NAME   ".svn"
#endif

Inside configure.in add

SVN_WORKINGDIR=".svn"
AC_SUBST(SVN_WORKINGDIR)

The above would be so the .pl and .py know what to look for. I'm unfortunately not adept enough to figure out whether your are on a windows machine or not from a configure file. Check if something like this compiles ?

#ifdef _WINDOWS
	return 0
#else
      return 1
#endif


Some documentation change will be required, i.e. either add (svn under windows) after every mention of .svn or add a global notice or use variable substitution inside the documentation by adding a lot of .in files.

I'm not on the list, but please include me in the correspondence regarding this issue. In particular, if you need me to go through all the documentation before you approve this, I'll do it. SourceSafe is such a pain and CVS is showing its age.

Philippe Lavoie
 
   Cactus Commerce         eBusiness. All Business.
 Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921
www.cactuscommerce.com philippe.lavoie@cactuscommerce.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUG] The client can't use a different directory than .svn

[kf...@collab.net]

I thought this was a problem with only ASP.NET?  (Not saying it's not
a problem, just trying to get the scope right.)

-K

"Philippe Lavoie" <ph...@cactus.ca> writes:
> I've browed the archive a bit and the issue has been raised a couple of times already and I'd like to raise it again. As some of you know IIS has some quirks. One of them is that it can't cope with a file which is only an extension, i.e. .svn. 
> 
> This means that any development of a web application causes errors from Visual Studio .NET (and older versions too). This is really dumb on IIS's part, but it might never be fixed by Microsoft. Therefore, I would hope that perhaps subversion could be told to use another directory. 
> 
> Somebody said that a potential solution would be that for now, in a Windows world svn would be used and in unix .svn. That solution has the advantage of being easy to implement in the short term. Somebody also said that if somebody really cared about this, they'd generate a patch for it...
> 
> I really care about this as otherwise subversion will never be approved by our company as an 'accepted' tool. So here is a patch for this. Somepeople raised the concern that people wouldn't be able to just drop a working copy from unix onto windows, well it's true for more than just the .svn vs svn reason. The end of line character can really cause headaches when you go from one system to the other. You are better off creating a working branch and doing updates from one system to the other (my 2 cents).
> 
> Anyway, here is the patch. Inside include/svn_wc.h
> 
> At the line 692 replace 
> 
> #define SVN_WC_ADM_DIR_NAME   ".svn"
> 
> with
> 
> #ifdef _WINDOWS
> 	#define SVN_WC_ADM_DIR_NAME  "svn"
> #else
> 	#define SVN_WC_ADM_DIR_NAME   ".svn"
> #endif
> 
> Inside configure.in add
> 
> SVN_WORKINGDIR=".svn"
> AC_SUBST(SVN_WORKINGDIR)
> 
> The above would be so the .pl and .py know what to look for. I'm unfortunately not adept enough to figure out whether your are on a windows machine or not from a configure file. Check if something like this compiles ?
> 
> #ifdef _WINDOWS
> 	return 0
> #else
>       return 1
> #endif
> 
> 
> Some documentation change will be required, i.e. either add (svn under windows) after every mention of .svn or add a global notice or use variable substitution inside the documentation by adding a lot of .in files.
> 
> I'm not on the list, but please include me in the correspondence regarding this issue. In particular, if you need me to go through all the documentation before you approve this, I'll do it. SourceSafe is such a pain and CVS is showing its age.
> 
> Philippe Lavoie
>  
>    Cactus Commerce         eBusiness. All Business.
>  Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921
> www.cactuscommerce.com philippe.lavoie@cactuscommerce.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org