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
Received on Thu Sep 25 11:32:41 2003