You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "James M. Lawrence" <qu...@yahoo.com> on 2006/10/26 14:56:27 UTC
case insensitivity revisited
I have a devilish subversion / emacs / OS X related bug.
(1) Foo.h contains a syntax error
(2) in some source file: #include "foo.h"
(3) I hit my compile key
(4) gcc reports foo.h:45:syntax error blah blah
(5) I hit my next-error key
(6) emacs opens foo.h
(7) I edit foo.h
(8) I save foo.h (which overwrites Foo.h)
(9) svn status:
? foo.h
! Foo.h
It's not enough just the check for case conflicts with an svn hook. I
am dealing with hundreds files here. I could write a script which
renames files, but that is getting messy. The default behavior should
be correct in the first place.
I see several possible solutions:
(a) the svn client could treat foo.h and Foo.h the same.
(b) emacs could have canonicalized the filename in the first place.
(c) gcc could have a flag to canonicalize reported filenames.
(d) reinstall OS X using case-sensitive HFS+ (forcing an error at
#include "foo.h").
(I am using carbonized emacs from darwinports.)
My own opinion is that case-preserving, case-insensitive filesystems
are conceptually broken when mixed with case-sensitive filesystems.
The problem is not the filesystem per se, but that there is no
enforced convention for tools which deal with the filesystem.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Thursday, October 26, 2006 7:56 AM -0700 "James M. Lawrence"
<qu...@yahoo.com> wrote:
> (d) reinstall OS X using case-sensitive HFS+ (forcing an error at
> #include "foo.h").
I'd vote for this one. Or get gcc to somehow check the case of the filename
found. This is a portability error, and will cause your code to break when
compiled on a case-sensitive system.
I continue to run into this with code developed on Windows that's ported to
Linux. Not just C/C++, but also web files that are moved from an IIS server
to Apache on a case-sensitive server. Just the other day I ran into this
with some HTML documentation for a game addon that I moved to my Apache
server for the benefit of other users. The background image file was
referenced in the body style with the wrong case, so the page rendered with
the client's default background color, quite ugly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Ted Dennison <de...@ssd.fsi.com>.
Dan Armbrust wrote:
> Well, Subversion may work correctly. But Susie Q web developer is
> writing webpages on her windows machine. She is using some broken
> application which decides it feels like renaming foo.htm to Foo.htm.
> Her links to foo.htm still work for her, on her windows machine. She
> checks in her changes, and Subversion does the right thing and picks
> up the rename.
>
> A server administrator checks them out onto a unix machine, and
> deploys them, and now many of her links are broken. All you have done
> is push the user error somewhere else, and made it more difficult to
> detect and find.
I agree that's a problem, but it has nothing to do with Subversion. If
there were no revision control in the loop, the exact same problem would
occur.
Anyway, under the scheme I was talking about, you'd still have no
problem. When Susie asks to check in Foo.htm, Subversion sees that she's
on a case-insensitive filesystem and updates "foo.htm" instead, and
things still work under Unix just fine.
> Yes, that is exactly what it is. A bug in your tools. Windows is a
> case-preserving file system. If you tools are not preserving the
> case, then they are not working the same way as the file system.
I think its more accurate to say "Windows is a case-agnostic file
system." Sure, filesystem file updates generally won't change the
filesystem's casing of the filename, but the operational reality is that
very few tools care. Any tool that caches a filename in some kind of
config file on Windows expects that the casing is not significant. This
includes many of the OS vendor's own tools. VisualStudio for one. Yeah,
you could try to claim this is just another "bug" in VisualStudio, but
it won't really help me any. I still have to get it to work, and it
works just fine when VisualStudio is talking to VSS. Its only Subversion
that has a problem.
> If you must use tools that make such poor assumptions about the world
> they live in, then maybe you will need to use an all lowercase naming
> scheme with your files.
That doesn't even help for working copies, as the file's parent
directory's casing can be an issue too. Windows also doesn't care if I
call my base hard drive "C:\" or "c:\".
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Dan Armbrust <da...@gmail.com>.
>>
>> This would just create a massive mess when you are going back and
>> forth between case sensitive and case insensitive platforms.
Well, Subversion may work correctly. But Susie Q web developer is
writing webpages on her windows machine. She is using some broken
application which decides it feels like renaming foo.htm to Foo.htm.
Her links to foo.htm still work for her, on her windows machine. She
checks in her changes, and Subversion does the right thing and picks up
the rename.
A server administrator checks them out onto a unix machine, and deploys
them, and now many of her links are broken. All you have done is push
the user error somewhere else, and made it more difficult to detect and
find.
> Some will
> give my working copy file's name or parent path in the filesystem's
> case, some convert it all to lower case. The user has no control over
> this, and you can't really call it a "bug" with the tools,
Yes, that is exactly what it is. A bug in your tools. Windows is a
case-preserving file system. If you tools are not preserving the case,
then they are not working the same way as the file system.
If you must use tools that make such poor assumptions about the world
they live in, then maybe you will need to use an all lowercase naming
scheme with your files.
What tool does this, by the way?
Dan
--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Ted Dennison <de...@ssd.fsi.com>.
Dan Armbrust wrote:
> Ted Dennison wrote:
>> Mine remains that the user tools, when used on a case-insensitive
>> filesystem, should be smart enough to recognize this fact and behave
>> in a case-insensitive manner. Of course this is easy for me to say,
>> as I'm a user, not a dev. Implementing this probably involves passing
>> case-sensitivity information to the server on every single call,
>> which would be a huge change.
>>
>
> This would just create a massive mess when you are going back and
> forth between case sensitive and case insensitive platforms.
I don't understand this comment. Presumably, when you go back to a
case-sensitive platform, it would behave case-sensitively under the
scheme I outlined. The only way I could see you'd have an issue is if
you have two files with the same name and different case, in which case
the insensitive system will have problems no matter what you do.
Perhaps we are thinking of different schemes?
> Seems to me that this is completely a user error.
Not so. For instance, some (non-svn) tools in my toolchain return the
system's drive letter uppercase, and some return it lowercase. Some will
give my working copy file's name or parent path in the filesystem's
case, some convert it all to lower case. The user has no control over
this, and you can't really call it a "bug" with the tools, because they
are Windows tools that only run on Windows, where files are
case-insensitive. That Subversion has problems with this can only be
seen as a Subversion problem.
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Dan Armbrust <da...@gmail.com>.
Ted Dennison wrote:
> James M. Lawrence wrote:
>> My own opinion is that case-preserving, case-insensitive filesystems
>> are conceptually broken when mixed with case-sensitive filesystems.
>> The problem is not the filesystem per se, but that there is no
>> enforced convention for tools which deal with the filesystem.
>>
> Mine remains that the user tools, when used on a case-insensitive
> filesystem, should be smart enough to recognize this fact and behave in
> a case-insensitive manner. Of course this is easy for me to say, as I'm
> a user, not a dev. Implementing this probably involves passing
> case-sensitivity information to the server on every single call, which
> would be a huge change.
>
>
This would just create a massive mess when you are going back and forth
between case sensitive and case insensitive platforms.
Seems to me that this is completely a user error.
You should not be relying on the case-insensitivity of a file system to
make your software work correctly. Be consistent with your file names,
and you wouldn't have a problem to start with.
Having subversion mangle things only passes the error farther down the
line, to the next user.
Dan
--
****************************
Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Ted Dennison <de...@ssd.fsi.com>.
James M. Lawrence wrote:
> My own opinion is that case-preserving, case-insensitive filesystems
> are conceptually broken when mixed with case-sensitive filesystems.
> The problem is not the filesystem per se, but that there is no
> enforced convention for tools which deal with the filesystem.
>
Mine remains that the user tools, when used on a case-insensitive
filesystem, should be smart enough to recognize this fact and behave in
a case-insensitive manner. Of course this is easy for me to say, as I'm
a user, not a dev. Implementing this probably involves passing
case-sensitivity information to the server on every single call, which
would be a huge change.
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 26 Oct 2006, at 15:56, James M. Lawrence wrote:
>
> I see several possible solutions:
>
> (a) the svn client could treat foo.h and Foo.h the same.
> (b) emacs could have canonicalized the filename in the first place.
> (c) gcc could have a flag to canonicalize reported filenames.
> (d) reinstall OS X using case-sensitive HFS+ (forcing an error at
> #include "foo.h").
>
> (I am using carbonized emacs from darwinports.)
>
> My own opinion is that case-preserving, case-insensitive filesystems
> are conceptually broken when mixed with case-sensitive filesystems.
> The problem is not the filesystem per se, but that there is no
> enforced convention for tools which deal with the filesystem.
(e) fix emacs so that it doesn't silently rename files when you save
them after modification.
I'd seriously avoid option d on your start-up drive since from the
beginning of (Mac) time, developers have known the Mac file system is
case insensitive, case preserving. Who knows what software will break.
My opinion is that case sensitive file systems are conceptually
broken. (Jeremy Pereira and jeremy pereira are recognisably the same
person. Why are computers different?) However, we have to live
with the situation we have got and I can't see a way of making
Subversion work differently that doesn't break things in other
horrible ways.
By the way, on Mac the following:
#include <stdio.h>
int main ()
{
FILE* fp = fopen ("bar", "w") ;
if (fp != NULL)
{
fprintf (fp, "Hello\n") ;
fclose (fp) ;
}
return 0 ;
}
will preserve the case of a file named "Bar", but
vi bar
<edits>
:wq
does not (vi has the same issue as emacs).
"open -a xcode bar" preserves case correctly as you'd hope for a Mac
application.
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by "James M. Lawrence" <qu...@yahoo.com>.
--- Ted Dennison <de...@ssd.fsi.com> wrote:
> I think we are talking about essentially the same thing. The only
> difference is that I'm thinking of it as something done automatically
> for you on case-insensitive OSes, rather than an option. The
> implementation issues should still be the same.
>
> Unless you were thinking of doing this *just* for the status command,
> and not fixing updates and the other client commands?
I realized that potential confusion just after posting. I meant the
hypothetical option would apply to all relevant commands. I picked
out the status command as an example.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by Ted Dennison <de...@ssd.fsi.com>.
James M. Lawrence wrote:
>> (a) the svn client could treat foo.h and Foo.h the same.
>>
>
> I was hoping to get a response to this option. What if the svn client
> had an option (perhaps a compile option) which would cause this to
> never happen:
>
> enkidu% svn status
> ! Foo.h
> ? foo.h
>
I think we are talking about essentially the same thing. The only
difference is that I'm thinking of it as something done automatically
for you on case-insensitive OSes, rather than an option. The
implementation issues should still be the same.
Unless you were thinking of doing this *just* for the status command,
and not fixing updates and the other client commands?
--
T.E.D. Work - mailto:dennison@ssd.fsi.com
Home - mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage - http://www.telepath.com/~dennison/Ted/TED.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: case insensitivity revisited
Posted by "James M. Lawrence" <qu...@yahoo.com>.
> (a) the svn client could treat foo.h and Foo.h the same.
I was hoping to get a response to this option. What if the svn client
had an option (perhaps a compile option) which would cause this to
never happen:
enkidu% svn status
! Foo.h
? foo.h
I understand that depending on case-insensitivity is wrong. It
wouldn't happen if it were my code. But it's not my code; I'm porting
a relatively large existing code base. I plan to reformat my hard
disk with a case-sensitive (non-boot) partition, but I cannot do that
right now.
In the meantime, what would be the harm of an svn client option for
which the above 'svn status' reports no change? It would merely be a
stop-gap measure to help developers stay productive, and would be
advertised as such. It would not be the default behavior.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org