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
Received on Thu Oct 26 16:57:13 2006