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

Re: ".svn" directory name no good (in fact, it is worse than I thought)

From: Files <files_at_poetryunlimited.com>
Date: 2003-09-25 18:18:50 CEST

Karl, could you use the script I posted?

Shamim Islam
BA BS

kvistgaard@users.sourceforge.net wrote:
>
>Well, I resisted coming out from the bushes and joining this thread
>for a while, hoping that someone would speak up for me. Apparently I'm
>a part of the small fraction of developers working in a heterogenous
>environment (i.e. Windows and *NIX) who would miss being able to
>easily move working copies (or WC fragments) between platforms.
>
>I'm not a VS.NET user myself, and thus do not experience the problem,
>but I can see why it's important to find a solution to this particular
>situation. As I understand the situation and this thread, the
>following options exist:
>
>1) Do nothing, it's a VS.NET problem
>2) Change a define on win32 from '.svn' to '_svn' (pre-1.0)
>3) Make the meta directory name configurable (post-1.0)
>4) Separate meta directories from the working copy (post-1.0)
>
>Not doing anything is obviously quite attractive since it's really
>non-intrusive :-)
>
>The one line change for 2) is code-wise very simple, but I think it
>robs Subversion of one of its attractive features (moving WC
>fragments), even if its "just" moving WC fragments across platforms.
>And the consequences of this change will stick until someone
>implements 3). I believe good people have convincingly argued the case
>against 3) before 1.0.
>
>I don't recall 4) being discussed in this context, but I believe its a
>candidate. To refresh peoples memories, Kumaran Santhanam did some
>experiments a while back on 4). Here's one of the threads:
>http://www.contactor.se/~dast/svn/archive-2003-08/1764.shtml
>
>I guess some of the questions people need to agree on are (add your
>own): Is a solution to the VS.NET problem required for 1.0? Is doing
>2) for 1.0 worth the consequences? What is the timeframe for
>alternative solutions, e.g. 3) and 4)? And last but not least, what
>can I do to help :-)
>
>
>Back to lurking again (promise :-). Regards
>
>-Morten
>
>
>Shawn wrote:
>> ++1
>> Yes I totally agree that this is an acceptable and viable solution. 99%
>> of Windows users won't ever want to give a *NIX user there working copy
>> and vice versa. The fact that this only affects the working copies means
>> windows clients can still use *NIX servers and vice versa. Also all the
>> third party utils are either platform specific or already have #defines
>> for win32 so this should be easy to do.
>>
>> -----Original Message-----
>> From: B. W. Fitzpatrick [mailto:fitz@red-bean.com]
>> Sent: September 24, 2003 11:05 PM
>> To: David Waite
>> Cc: Files; james-tigris@jrv.org; dev@subversion.tigris.org;
>> sussman@collab.net; roncannes@hotmail.com
>> Subject: Re: ".svn" directory name no good (in fact, it is worse than I
>> thought)
>>
>>
>> David Waite <mass@akuma.org> writes:
>>
>>>I'm not arguing for configuration, I'm arguing for the libraries, when
>>>compiled on for win32 platforms, use _svn for the directory name. I
>>>also am arguing against logic to 'support both' within the subversion
>>>libraries and command line client.
>>
>>
>> Excellent.
>>
>> If you toss in some documention, and a FAQ entry on why we have _svn
>> dirs on windows, this has my +1.
>>
>> -Fitz
>>
>> --
>> Brian W. Fitzpatrick <fitz@red-bean.com>
>> http://www.red-bean.com/fitz/
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 18:32:42 2003

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

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