B. W. Fitzpatrick wrote:
>Files <files@poetryunlimited.com> writes:
>
>
>
>>Just keep thinking that this is the kind of thing that would go away if
>>we didn't do something special.
>>
>>I do know that on my windows machine, I cannot create via explorer a
>>.<anything> file. It croaks. Even worseon a network machine.
>>
>>In order to create a .htaccess file, I have to create a .htaccess.txt
>>file and then tell apache to use that instead.
>>
>>
>
>A workaround... and from what I can tell, there's currently a workaround
>for this problem on Windows, no?
>
>
Yes, either don't use revision control, change the constant yourself and
compile subversion, or move the revision directories out of the way
while using your IDE.
With .svn directories, I get a warning while opening ASP.NET projects,
and am completely unable to add an existing project.
>>However, if the system software happens to do it, or a library call
>>happens to do it, it usually causes no problems. (I can rename at the
>>command line).
>>
>>So perhaps there is something in the system libraries on Windows that is
>>causing interference when the backwards compatibility to MSDOS is
>>bypassed and LFNs are used via Windoze only libraries?
>>
>>Wouldn't something as simple as SVN insteade of a leading dotted path
>>component handle it all? Or were people up in arms because we could see
>>the directory and not have unix automagically hide it.
>>
>>
>
>I dunno. This bugs me a) because I'm tired of rehashing this and b) why
>do *we* have to compensate for some other vendor's broken-ass software?
>
>
Because CVS, the system subversion is subverting, does not have this
problem with this vendor's software? Because every commercial revision
system does not have this problem with this vendor's software?
Because the workaround (telling people to use scripts or just not
version control a large part of their projects) may wind up hurting
adoption among windows developers?
>>And lastly, why *isn't* the admin path configurable with a .svn default?
>>How does interoperability have to do with a path component that is
>>localized to a current filesystem where the library is already
>>intelligent enough to know where the admin textbase is located via the
>>configuration file or command line override?
>>
>>
>
>We've been through all of this a *million* times in the last 3.5
>years--the name of the admin directory, why we don't want it
>configurable by a directive... the list goes on... and quite frankly,
>I'm just tired of arguing about it.
>
>We discuss and discuss and discuss and make a decision and a year later,
>folks show up with a million reasons (I'm not going to argue about the
>validity of these reasons) why we should have zigged when we zagged.
>I'll betcha five bucks that if we change it to SVN, a year from now
>*someone* will have 50 reasons (just as valid) why we should change it
>*back* to .svn. *thud*
>
>This isn't directed at you, Shamim--this is just one of the hazards of
>doing Open Source development. *sigh*
>
>
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.
I personally have just 'learned to deal' with it. I no longer spend
hours trying to figure out why I can't reload a moved project, I know
right away what is causing it.
However, if I hadn't already put significant time and effort falling in
love with subversion before I had one of these half-day delays trying to
figure out why my project wouldn't load, you better believe I would
still be using CVS today.
I'm sure the same argument might also be made for mac developers and the
lack of opaque collections. The difference is that the fix for the win32
problem could be a single #ifdef'd #define.
There, I made my strong sell, thats out of my system.
Right now we are alpha, changing that define causes an annoying but
acceptable re-checkout of working copies, or migration tool for
.svn->_svn. Once we hit 1.0, it will be much less acceptable to change
this and break (millions) of deployed environments. Let us just declare
this the point where we decide for 1.0, and that the decision cannot be
changed until at least 2.0.
And let us start a subversion page for known issues and workarounds,
such as this vs.net/asp.net problem and mac bundles.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 08:02:47 2003