You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Files <fi...@poetryunlimited.com> on 2003/09/25 04:05:46 UTC
Re: ".svn" directory name no good (in fact, it is worse than I
thought)
Out of idle curiosity, since we all seem to be so big on CVS
compatibility and the like, I'm surprised that we never ended up with
SVN as the name of the admin path.
Wouldn't that have solved it? Since it is truly portable across all
filesystems - including one's with braindead extension systems a la 8.3
etc?
Is it too late to revisit that now? Just wondering.
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.
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.
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?
A lot of questions, I know. I'm just thinking out loud. Hope some of
this has been useful. I just feel like standardization was co-opted for
uniformity instead.
I'm going to bed. Hope to see some interesting thoughts in the morning.
Later all.
On Wed, 2003-09-24 at 21:30, james-tigris@jrv.org wrote:
> The admin dir is #defined to '.svn', so in theory, it *could* be
> user-configurable, or just different on win32. But we had this
> discussion years ago, and wanted people to converge on a single
> interoperable standard.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Branko Čibej <br...@xbc.nu>.
David Waite wrote:
> B. W. Fitzpatrick wrote:
>
>> 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.
Has anyone filed a bug report with Microsoft about this? Or are we just
assuming nothing can be done about it becuase the On High have Decided,
and that's it?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by David Waite <ma...@akuma.org>.
Hypothetically, say that we go with this: should we push to have a
'test' release with the change so people can evaluate it in their
windows environments ,and make _sure_ nothing complains?
-David Waite
B. W. Fitzpatrick wrote:
>David Waite <ma...@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 <fi...@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
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Francois Beausoleil <fb...@users.sourceforge.net>.
I wonder, there was a person here that had a patch that would allow .svn
admin directories to live outside the project folder. Wouldn't that be
another option ?
Thanks,
François
On Thu, 25 Sep 2003 01:05:17 -0500, "B. W. Fitzpatrick"
<fi...@red-bean.com> said:
>
> David Waite <ma...@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 <fi...@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
>
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
David Waite <ma...@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 <fi...@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
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Scott Moynes <sm...@nerdnest.org>.
* David Waite (mass@akuma.org) wrote:
> 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.
And what happens when another IDE has a problem with _svn rather than
.svn? If the developers decide to change the directory name at this
point, I think creating a knob to tweak in ~/.subversion/config would
help prevent future problems with other stupid software.
--
Scott Moynes
"Computer science is as much about computers
as astronomy is about telescopes." -- Dijkstra
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by David Waite <ma...@akuma.org>.
B. W. Fitzpatrick wrote:
>Files <fi...@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
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
Files <fi...@poetryunlimited.com> writes:
> Out of idle curiosity, since we all seem to be so big on CVS
> compatibility and the like, I'm surprised that we never ended up with
> SVN as the name of the admin path.
>
> Wouldn't that have solved it? Since it is truly portable across all
> filesystems - including one's with braindead extension systems a la 8.3
> etc?
>
> Is it too late to revisit that now? Just wondering.
At what point do we stop revisiting things?
> 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?
> 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?
> 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*
-Fitz
--
Brian W. Fitzpatrick <fi...@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
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by "C.Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > 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?
>
> It means I can't hand you my working copy. Why not? Because I just
> happen to use "7ex983p" as my admin directory names. I like it.
>
> "Oh, you want to read my working copy too? I guess you'd better
> temporarily configure your client to use that same admin directory
> name. You can change your configuration back later."
We could always go with a configuration option for allowable
additional names for admin dirs. That is, make the client code expect
.svn (as in, *always* try that first), and failing that, try the
ordered list of names in that config option.
This means you pay no penalty for continuing to use .svn (and by the
way, we still would never allow you to version a path named ".svn",
regardless of your current WC admin name). Folks who want to use
something else will pay the try-fail-try-again cost, but, well, that's
just tough.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Steve Williams <st...@kromestudios.com>.
All this to work-around a deficiency in VS.NET with ASP.NET projects?
So what that Windows Explorer cannot create a folder such as '.svn'? It can
be easily done via the command-line. Mention was also made of some Win32
API functions that don't handle these directory names either, but I also
notice that no-one came up with specific function names.
Sly
----- Original Message -----
From: <kf...@collab.net>
To: "Ben Collins-Sussman" <su...@collab.net>
Cc: "Files" <fi...@poetryunlimited.com>; <ja...@jrv.org>;
<de...@subversion.tigris.org>; <ro...@hotmail.com>
Sent: Thursday, September 25, 2003 1:51 PM
Subject: Re: ".svn" directory name no good (in fact, it is worse than I
thought)
> Ben Collins-Sussman <su...@collab.net> writes:
> > It means I can't hand you my working copy. Why not? Because I just
> > happen to use "7ex983p" as my admin directory names. I like it.
> >
> > "Oh, you want to read my working copy too? I guess you'd better
> > temporarily configure your client to use that same admin directory
> > name. You can change your configuration back later."
>
> The other issue is that we treat this directory specially in certain
> situations -- for example, import ignores it, other operations may
> balk at working on it. If we also allow "_svn", then all those
> conditionals have to change, and now we have *two* reserved names
> instead of one. Third-party tools have to try *two* possibilities to
> determine if a directory is a Subversion working copy or not... Where
> does it end?
>
> Violate the 0-1-infinity principle, pay the price.
>
> ---------------------------------------------------------------------
> 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
RE: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Shawn <di...@shaw.ca>.
By not addressing the problem you are really forcing VS.NET users to do
1 of 2 things.
1) Not use subversion or
2) Branch the source code and fix the problem themselves and then
distribute the new branch to other VS.NET users.
I don't think you want either of these 2 cases to happen. In both cases
the subversion project looses.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by "B. W. Fitzpatrick" <fi...@red-bean.com>.
Shawn <di...@shaw.ca> writes:
> I have a question about the actual implementation of the .svn dirs. Is
> there one single constant use throughout the source so that this change
> could be made by simply changing one line of code?
One line of code.
> Or is ".svn" littered throughout the codebase? It just seems like the
> developers are baulking at this issue because they know how much work
> changing it would entail. I know that on my own personal projects
> I've made decisions about the "seriousness" of a bug based on how long
> it would take to fix it. Who is responsible for determining the
> seriousness of issues like this?
The committers, with feedback from the members of the list taken into
account. Changing it to something other than .svn isn't too
hard--changing Subversion to accomodate more than one possible name for
administrative directories is considerably more hairy, as Karl pointed
out.
fI for one am content with .svn and will vote -1 on any attempt to
change it--we've been through this all before and I'm not about to go
through it again, especially this close to beta. I'm really sorry about
the .Net bugs and all, but we shouldn't be painting this bikeshed this
close to the finish line.
-Fitz, curmudgeon-at-large
--
Brian W. Fitzpatrick <fi...@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
RE: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Shawn <di...@shaw.ca>.
I have a question about the actual implementation of the .svn dirs. Is
there one single constant use throughout the source so that this change
could be made by simply changing one line of code? Or is ".svn" littered
throughout the codebase? It just seems like the developers are baulking
at this issue because they know how much work changing it would entail.
I know that on my own personal projects I've made decisions about the
"seriousness" of a bug based on how long it would take to fix it. Who is
responsible for determining the seriousness of issues like this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> It means I can't hand you my working copy. Why not? Because I just
> happen to use "7ex983p" as my admin directory names. I like it.
>
> "Oh, you want to read my working copy too? I guess you'd better
> temporarily configure your client to use that same admin directory
> name. You can change your configuration back later."
The other issue is that we treat this directory specially in certain
situations -- for example, import ignores it, other operations may
balk at working on it. If we also allow "_svn", then all those
conditionals have to change, and now we have *two* reserved names
instead of one. Third-party tools have to try *two* possibilities to
determine if a directory is a Subversion working copy or not... Where
does it end?
Violate the 0-1-infinity principle, pay the price.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ".svn" directory name no good (in fact, it is worse than I thought)
Posted by Ben Collins-Sussman <su...@collab.net>.
Files <fi...@poetryunlimited.com> writes:
> Out of idle curiosity, since we all seem to be so big on CVS
> compatibility and the like, I'm surprised that we never ended up with
> SVN as the name of the admin path.
That was the original name, three years ago. Then everyone cheered we
changed it to .svn/
> Is it too late to revisit that now? Just wondering.
I think the commandline users (unix folk) really were happy when the
directory became invisible... at the moment, I'd rather go with Jack
Repenning's plan: create _svn on win32, .svn on unix, and the client
tolerates either format when reading.
> 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?
It means I can't hand you my working copy. Why not? Because I just
happen to use "7ex983p" as my admin directory names. I like it.
"Oh, you want to read my working copy too? I guess you'd better
temporarily configure your client to use that same admin directory
name. You can change your configuration back later."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org