Can SVN Check for too long and CamelCase file names?
I have recently had my wrist slapped by John Maddock, not once, but twice :-(( My offences were committing both Too long filenames, and CamelCaseFileNames. Are either of these crimes that could be prevented by SVN pre-commit rules? Paul PS I have submiited a Trac ticket for Quickbook documentaiton update http://svn.boost.org/trac/boost/ticket/1221 --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On 8/28/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
Are either of these crimes that could be prevented by SVN pre-commit rules?
Definitely. There are already some user-contributed hook scripts that ship with the Subversion sources that do even more complex checks than this, like one that "normalizes" all filenames to lowecase and looks for conflicts (e.g. README and ReadMe in the same directory would be disallowed). I am sure writing a simple check like filename.lower() == filename or filename.length() < N should be pretty simple. Attached is my simplistic attempt at this, adapted from the skeleton pre-commit-check Python script that ships with the Subversion sources. Not sure what the correct maximum filename limit is - I chose 32. -- Caleb Epstein
Caleb Epstein wrote:
On 8/28/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
Are either of these crimes that could be prevented by SVN pre-commit rules?
Definitely. Attached is my simplistic attempt at this, adapted from the skeleton pre-commit-check Python script that ships with the Subversion sources As has been said in a previous, similar discussion, simple disallowing of upper-case characters doesn't work. Bjam's files are called Jamroot and Jamfile, and the capitalization matters.
Sebastian Redl
Sebastian Redl wrote:
Caleb Epstein wrote:
On 8/28/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
Are either of these crimes that could be prevented by SVN pre-commit rules?
Definitely. Attached is my simplistic attempt at this, adapted from the skeleton pre-commit-check Python script that ships with the Subversion sources
As has been said in a previous, similar discussion, simple disallowing of upper-case characters doesn't work. Bjam's files are called Jamroot and Jamfile, and the capitalization matters.
Ah, no ;-) Boost.Build will handle any of: project-root.jam [Jj]amroot [Jj]amroot.jam [Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile.jam I personally prefer the ones with the .jam extension :-) But I don't see a problem with using capital letters in file names. And more important, the restriction may not be appropriate for all file/dir names in the svn repo. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
On 8/28/07, Rene Rivera <grafikrobot@gmail.com> wrote:
Sebastian Redl wrote:
As has been said in a previous, similar discussion, simple disallowing of upper-case characters doesn't work. Bjam's files are called Jamroot and Jamfile, and the capitalization matters.
I personally prefer the ones with the .jam extension :-) But I don't see a problem with using capital letters in file names. And more important, the restriction may not be appropriate for all file/dir names in the svn repo.
Perhaps the canned check-case-insensitive.py script that comes with Subversion would be a better fit then. It checks that there are no collisions within any directory if filenames are case-flattened (e.g. Jamfile would be OK, but not in the same directory with jamfile). http://subversion.tigris.org/tools_contrib.html#check_case_insensitive_py -- Caleb Epstein
Rene Rivera wrote:
As has been said in a previous, similar discussion, simple disallowing of upper-case characters doesn't work. Bjam's files are called Jamroot and Jamfile, and the capitalization matters.
Ah, no ;-) Boost.Build will handle any of:
project-root.jam [Jj]amroot [Jj]amroot.jam [Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile.jam
I personally prefer the ones with the .jam extension :-) But I don't see a problem with using capital letters in file names. And more important, the restriction may not be appropriate for all file/dir names in the svn repo.
Note that our submission policy (http://www.boost.org/more/lib_guide.htm#Directory_structure) states: "File and directory names must contain only lowercase ASCII letters , numbers, underscores, and a period. Leading character must be alphabetic. Maximum length 31. Only a single period is permitted. These requirements ensure file and directory names are relatively portable." John.
John Maddock wrote:
Rene Rivera wrote:
As has been said in a previous, similar discussion, simple disallowing of upper-case characters doesn't work. Bjam's files are called Jamroot and Jamfile, and the capitalization matters.
Ah, no ;-) Boost.Build will handle any of:
project-root.jam [Jj]amroot [Jj]amroot.jam [Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile.jam
I personally prefer the ones with the .jam extension :-) But I don't see a problem with using capital letters in file names. And more important, the restriction may not be appropriate for all file/dir names in the svn repo.
Note that our submission policy (http://www.boost.org/more/lib_guide.htm#Directory_structure) states:
"File and directory names must contain only lowercase ASCII letters , numbers, underscores, and a period. Leading character must be alphabetic. Maximum length 31. Only a single period is permitted. These requirements ensure file and directory names are relatively portable."
We had files named Jamfile for year. I'm not aware of any practical problem that has caused. So, I don't think that even *discussing* handing the filename case, at least for Jamfiles, is a productive use of time. - Volodya
On Aug 28, 2007, at 5:15 AM, Paul A Bristow wrote:
I have recently had my wrist slapped by John Maddock, not once, but twice :-((
My offences were committing both
Too long filenames, and
It would be good to check for this.
CamelCaseFileNames.
What's wrong with these? It's certainly bad to have names that differ only by case, but CamelCaseFileNames by themselves aren't necessarily evil...
Are either of these crimes that could be prevented by SVN pre- commit rules?
Both can be, yes. - Doug
On Aug 28, 2007, at 5:15 AM, Paul A Bristow wrote:
I have recently had my wrist slapped by John Maddock, not once, but twice :-((
My offences were committing both
Too long filenames, and
CamelCaseFileNames.
Are either of these crimes that could be prevented by SVN pre- commit rules?
The Subversion repository now checks that there are no problems with case-insensitive file systems (based on the case-insensitive.py pre- commit hook). So committing "Jamfile" is file, but a commit of "JamFile" when there is already a "Jamfile" will be rejected. We also now reject commits containing filenames with > 31 characters. - Doug
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Doug Gregor Sent: 29 August 2007 16:46 To: boost@lists.boost.org Subject: Re: [boost] Can SVN Check for too long and CamelCase file names?
On Aug 28, 2007, at 5:15 AM, Paul A Bristow wrote:
I have recently had my wrist slapped by John Maddock, not once, but twice :-((
My offences were committing both
Too long filenames, and
CamelCaseFileNames.
Are either of these crimes that could be prevented by SVN pre- commit rules?
The Subversion repository now checks that there are no problems with case-insensitive file systems (based on the case-insensitive.py pre- commit hook). So committing "Jamfile" is file, but a commit of "JamFile" when there is already a "Jamfile" will be rejected.
We also now reject commits containing filenames with > 31 characters.
Thanks for saving my wrist from further chastisement by John ;-) Paul PS We still need to resolve WHY the original submission rules said "No uppercase". "These requirements ensure file and directory names are relatively portable" Are those requirements still valid on some platform? And we need to agree to change the requirements if we can agree they are no longer needed. --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
on Wed Aug 29 2007, "Paul A Bristow" <pbristow-AT-hetp.u-net.com> wrote:
PS We still need to resolve WHY the original submission rules said "No uppercase".
"These requirements ensure file and directory names are relatively portable"
Are those requirements still valid on some platform?
They are, on case-insensitive filesystems. If you make a file called "Axe.hpp" and then do #include "axe.hpp", it will work on your Windows machine under VC++, but will break when someone compiles on linux. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: 29 August 2007 17:13 To: boost@lists.boost.org Subject: Re: [boost] Can SVN Check for too long and CamelCase file names?
on Wed Aug 29 2007, "Paul A Bristow" <pbristow-AT-hetp.u-net.com> wrote:
PS We still need to resolve WHY the original submission rules said "No uppercase".
"These requirements ensure file and directory names are relatively portable"
Are those requirements still valid on some platform?
They are, on case-insensitive filesystems. If you make a file called "Axe.hpp" and then do #include "axe.hpp", it will work on your Windows machine under VC++, but will break when someone compiles on linux.
Well one could "say you've got the wrong filename" - on Windows? But I have no strong feelings on this. I've just made the mistake of using a capital letter - for fairly good reason - it was "binomial_NAG_example.cpp" Are sure there are no files with capitals already? (Not that I've seen any). If this is really the policy, it would seem sensible to have it enforced by SVN? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
David Abrahams wrote:
on Wed Aug 29 2007, "Paul A Bristow" <pbristow-AT-hetp.u-net.com> wrote:
PS We still need to resolve WHY the original submission rules said "No uppercase".
"These requirements ensure file and directory names are relatively portable"
Are those requirements still valid on some platform?
They are, on case-insensitive filesystems. If you make a file called "Axe.hpp" and then do #include "axe.hpp", it will work on your Windows machine under VC++, but will break when someone compiles on linux.
Right, and we've already had one problem of this kind when someone tried to build the Math Toolkit docs on Linux. There's also the issue of what happens if you move files from a case-insensitive system (CD-ROM?) to a case-sensitive one. Life is just much easier when the rule is followed, though I accept it's probably way too late for all those "Jamfiles". John.
on Wed Aug 29 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Life is just much easier when the rule is followed, though I accept it's probably way too late for all those "Jamfiles".
It's never too late. I don't see any good reason not to change them. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Wed Aug 29 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Life is just much easier when the rule is followed, though I accept it's probably way too late for all those "Jamfiles".
It's never too late. I don't see any good reason not to change them.
As I say in another email, it's just making work. I don't remember any single problem caused by spelling of "Jamfile", so updating all file names is useless effort that's not helping anybody. - Volodya
Vladimir Prus wrote:
David Abrahams wrote:
on Wed Aug 29 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Life is just much easier when the rule is followed, though I accept it's probably way too late for all those "Jamfiles". It's never too late. I don't see any good reason not to change them.
As I say in another email, it's just making work. I don't remember any single problem caused by spelling of "Jamfile", so updating all file names is useless effort that's not helping anybody.
Except if we rename to "jamfile.jam", or any other variation with a "jam" extension, then it is worthwhile work as it helps Windows users to associate the *.jam files to an appropriate editor. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Vladimir Prus wrote:
David Abrahams wrote:
on Wed Aug 29 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Life is just much easier when the rule is followed, though I accept it's probably way too late for all those "Jamfiles". It's never too late. I don't see any good reason not to change them.
As I say in another email, it's just making work. I don't remember any single problem caused by spelling of "Jamfile", so updating all file names is useless effort that's not helping anybody.
Except if we rename to "jamfile.jam", or any other variation with a "jam" extension, then it is worthwhile work as it helps Windows users to associate the *.jam files to an appropriate editor.
It might help them, but then again, this does not seem like the best use of your time ;-) - Volodya
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: 29 August 2007 18:39 To: boost@lists.boost.org Subject: Re: [boost] Can SVN Check for too long and CamelCase file names?
PS We still need to resolve WHY the original submission rules said "No uppercase".
"These requirements ensure file and directory names are relatively portable"
Are those requirements still valid on some platform?
Right, and we've already had one problem of this kind when someone tried to build the Math Toolkit docs on Linux.
Would it help to convince people to explain WHY this breaks? Paul
participants (8)
-
Caleb Epstein -
David Abrahams -
Doug Gregor -
John Maddock -
Paul A Bristow -
Rene Rivera -
Sebastian Redl -
Vladimir Prus