You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "John M. Black" <jo...@gmail.com> on 2008/03/21 01:42:06 UTC
Ignore patterns should not be case sensitive (usability)
(Before I begin, let me say this is *not* about the filesystem itself;
I respect the current decision to keep filesystem operations
case-sensitive.)
However, making *Ignore patterns* case-sensitive is I think
counterintuitive for this particular feature. The typical use case
for Ignore is to ignore all files of a certain type, most of which
will be encountered at some point in the future and don't exist yet.
Can anyone think of a use case where a user or group of users would
intentionally want to ignore .TXT files but not .txt or .Txt files?
Imagine trying to cover all the bases. You'd have to add:
.TXT
.TXt
.TxT
.tXT
.Txt
.tXt
.txT
.txt
I for one don't feel like entering every file extension 8 times.
Please consider making Ignore pattern-matching case insensitive.
OR at the very least, let the user choose. Maybe the easiest way to
do this is to keep the current Ignore property intact, and add a new
property "svn:ignoreNoCase". That way users can have it either way
for any item.
Thanks for your time,
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Chris Rose <ch...@messagingdirect.com>.
Karl Fogel wrote:
> "Kevin Grover" <ke...@kevingrover.net> writes:
>
>> How about adding configuration options to svn:ignore? Like .hgignore
>> does for setting the syntax.
>> eg.
>> --------------------------- .hgignore
>> # use glob syntax.
>> syntax: glob
>>
>> *.elc
>> *.pyc
>> *~
>> .*.swp
>>
>> # switch to regexp syntax.
>> syntax: regexp
>> ^\.pc/
>> --------------------------- .hgignore
>>
>> SVN could have an option:
>> option: [+-]casesensative
>>
>> Where +casentative is the default option (and this maintains comapitility.
>> If this could potentially break current properties lists, there could
>> be another svn:ignore-options where these were set.
>>
>> In the processes, couldn't '# blah...' be allowed as comments?
>>
>
> Neat idea! I kind of like that, and it's hard to imagine that anyone
> has actually set ignore properties for files matching the regexp:
>
> ^option: [a-z0-9]+
>
> In other words, it is effectively backwards-compatible.
>
> Anyone think this is a bad idea?
>
I don't think it's a bad idea, per se, but I think that Kevin's
description of Mercury's format should be included as well; if svn
supports both option: and syntax: forms, then it's possible to provide a
nice, flexible svn:ignore to all comers.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Kevin Grover" <ke...@kevingrover.net> writes:
> How about adding configuration options to svn:ignore? Like .hgignore
> does for setting the syntax.
> eg.
> --------------------------- .hgignore
> # use glob syntax.
> syntax: glob
>
> *.elc
> *.pyc
> *~
> .*.swp
>
> # switch to regexp syntax.
> syntax: regexp
> ^\.pc/
> --------------------------- .hgignore
>
> SVN could have an option:
> option: [+-]casesensative
>
> Where +casentative is the default option (and this maintains comapitility.
> If this could potentially break current properties lists, there could
> be another svn:ignore-options where these were set.
>
> In the processes, couldn't '# blah...' be allowed as comments?
Neat idea! I kind of like that, and it's hard to imagine that anyone
has actually set ignore properties for files matching the regexp:
^option: [a-z0-9]+
In other words, it is effectively backwards-compatible.
Anyone think this is a bad idea?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Kevin,
the svn:ignore is already glob syntax and global-ignores in config file
as well.
Same discussion on the user@ list...
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Kevin Grover" <ke...@kevingrover.net> writes:
> How about adding configuration options to svn:ignore? Like .hgignore
> does for setting the syntax.
> eg.
> --------------------------- .hgignore
> # use glob syntax.
> syntax: glob
>
> *.elc
> *.pyc
> *~
> .*.swp
>
> # switch to regexp syntax.
> syntax: regexp
> ^\.pc/
> --------------------------- .hgignore
>
> SVN could have an option:
> option: [+-]casesensative
>
> Where +casentative is the default option (and this maintains comapitility.
> If this could potentially break current properties lists, there could
> be another svn:ignore-options where these were set.
>
> In the processes, couldn't '# blah...' be allowed as comments?
Neat idea! I kind of like that, and it's hard to imagine that anyone
has actually set ignore properties for files matching the regexp:
^option: [a-z0-9]+
In other words, it is effectively backwards-compatible.
Anyone think this is a bad idea?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Kevin Grover <ke...@kevingrover.net>.
On Fri, Mar 21, 2008 at 10:36 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "John M. Black" <jo...@gmail.com> writes:
> > [...]
>
> >
> > Please consider making Ignore pattern-matching case insensitive.
> >
> > OR at the very least, let the user choose. Maybe the easiest way to
> > do this is to keep the current Ignore property intact, and add a new
> > property "svn:ignoreNoCase". That way users can have it either way
> > for any item.
>
> How about a new property, "svn:Ignore", that means...
>
> Okay, sorry, bad joke.
>
> We could use an extra property, like you say, or a run-time
> configuration option, or both. The run-time option is probably easiest
> to implement. Would it be a compatibility break to have that option
> turned on by default (given that a user could always turn it off)? I
> don't know.
>
> Another possibility: be case-insensitive just for patterns of the form
> "*.foo", which probably covers more than 90% of the use cases.
>
> I'm just tossing out ideas here. At some point, we should take this
> thread to dev@, and see if we can get consensus on a solution. I do see
> your point about how the current behavior is (usually) not great.
>
> -Karl
>
How about adding configuration options to svn:ignore? Like .hgignore
does for setting the syntax.
eg.
--------------------------- .hgignore
# use glob syntax.
syntax: glob
*.elc
*.pyc
*~
.*.swp
# switch to regexp syntax.
syntax: regexp
^\.pc/
--------------------------- .hgignore
SVN could have an option:
option: [+-]casesensative
Where +casentative is the default option (and this maintains comapitility.
If this could potentially break current properties lists, there could
be another svn:ignore-options where these were set.
In the processes, couldn't '# blah...' be allowed as comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Re: Ignore patterns should not be case sensitive (usability)
Posted by Jared Hardy <ja...@gmail.com>.
On Mon, Mar 24, 2008 at 1:18 PM, Erik Huelsmann <eh...@gmail.com> wrote:
> The svn:ignore property is a public interface, meaning that we can't
> change it until 2.0. Adding more properties which 'do almost the same'
> is definitely out of line with anything the Subversion developers have
> done so far and probably only serves to confuse.
That makes sense. I guess that means that case-insensitive ignores
requires a "new" interface in the 1.x versions. Something like a new
conf variable under [miscellany], called
"global-ignores-case-insensitive" would be useful.
I would just hope that all the developers could keep that
principle in mind in their future 2.0 work. Interface defaults should
always start with majority human assumptions, regardless of platform,
or other technical details.
Thanks!
Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Lorenz <lo...@yahoo.com>.
Les Mikesell wrote:
>Karl Fogel wrote:
>>
>> Plus a strategy that hasn't been discussed yet: using "/" as an escape
>> hatch, since "/" is meaningless in filename patterns (given that
>> Subversion and most platforms already reserve it as a path separator).
>>
>
>> Agreed, and if we were still worried about compatibility, we'd just
>> start such meta-syntactic lines with "/", like
>>
>> / option: case-insensitive
>> *.txt
>> *.obj
>> / option: case-sensitive
>> readme
>>
>> ...or something along those lines.
>
>Perhaps a simple and slightly perlish:
>*.txt/i
I was to propose the same because it resembles 'normal' regex syntax,
and has the potential to switch to more sophisticated regex.
--
Lorenz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Karl Fogel wrote:
>
> Plus a strategy that hasn't been discussed yet: using "/" as an escape
> hatch, since "/" is meaningless in filename patterns (given that
> Subversion and most platforms already reserve it as a path separator).
>
> Agreed, and if we were still worried about compatibility, we'd just
> start such meta-syntactic lines with "/", like
>
> / option: case-insensitive
> *.txt
> *.obj
> / option: case-sensitive
> readme
>
> ...or something along those lines.
Perhaps a simple and slightly perlish:
*.txt/i
could emultate the harder to type
*.[Tt][Xx][Tt]
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/26, Ryan Schmidt <su...@ryandesign.com>:
>
> On Mar 26, 2008, at 01:14, Henrik Sundberg wrote:
>
> > 2008/3/26, Karl Fogel:
>
> >
> >> Plus a strategy that hasn't been discussed yet: using "/" as an
> >> escape
> >> hatch, since "/" is meaningless in filename patterns (given that
> >> Subversion and most platforms already reserve it as a path
> >> separator).
> >
> > I would prefer the ability to match full paths.
> > I therefore think the "/" should be avoided.
>
>
> Ignore-patterns apply on a per-directory basis therefore full path
> matching is not relevant. If you think it is relevant, then that's a
> separate enhancement request.
It would be better to allow the same syntax for [auto-props] as for
ignores. Even if [auto-props] is a separate issue, I don't think the
design here should prevent a future enhancement.
Global ignores should be allowed to contain paths, in the same way as
[auto-props] should.
$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 26, 2008, at 01:14, Henrik Sundberg wrote:
> 2008/3/26, Karl Fogel:
>
>> Plus a strategy that hasn't been discussed yet: using "/" as an
>> escape
>> hatch, since "/" is meaningless in filename patterns (given that
>> Subversion and most platforms already reserve it as a path
>> separator).
>
> I would prefer the ability to match full paths.
> I therefore think the "/" should be avoided.
Ignore-patterns apply on a per-directory basis therefore full path
matching is not relevant. If you think it is relevant, then that's a
separate enhancement request.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/26, Karl Fogel <kf...@red-bean.com>:
> "Henrik Sundberg" <st...@gmail.com> writes:
> > 2008/3/26, Karl Fogel <kf...@red-bean.com>:
> >> Plus a strategy that hasn't been discussed yet: using "/" as an escape
> >> hatch, since "/" is meaningless in filename patterns (given that
> >> Subversion and most platforms already reserve it as a path separator).
> >
> > I would prefer the ability to match full paths.
> > I therefore think the "/" should be avoided.
>
>
> This would still leave leading "/" for meta syntax, since even if we
> support full path ignores someday, we wouldn't have any use for absolute
> paths.
Why not?
Wasn't that a part of the new rules for externals when solving this?
http://subversion.tigris.org/issues/show_bug.cgi?id=1336
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Henrik Sundberg" <st...@gmail.com> writes:
> 2008/3/26, Karl Fogel <kf...@red-bean.com>:
>> Plus a strategy that hasn't been discussed yet: using "/" as an escape
>> hatch, since "/" is meaningless in filename patterns (given that
>> Subversion and most platforms already reserve it as a path separator).
>
> I would prefer the ability to match full paths.
> I therefore think the "/" should be avoided.
This would still leave leading "/" for meta syntax, since even if we
support full path ignores someday, we wouldn't have any use for absolute
paths.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/26, Karl Fogel <kf...@red-bean.com>:
> Plus a strategy that hasn't been discussed yet: using "/" as an escape
> hatch, since "/" is meaningless in filename patterns (given that
> Subversion and most platforms already reserve it as a path separator).
I would prefer the ability to match full paths.
I therefore think the "/" should be avoided.
$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 26, 2008, at 16:14, Erik Huelsmann wrote:
>>> I agree with Karl that such a line is highly unlikely to be used in
>>> existing ignore rules such that it should not affect backward
>>> compatibility in practice.
>>>
>>> http://svn.haxx.se/users/archive-2008-03/0781.shtml
>>
>> Agreed, and if we were still worried about compatibility, we'd just
>> start such meta-syntactic lines with "/", like
>>
>> / option: case-insensitive
>> *.txt
>> *.obj
>> / option: case-sensitive
>> readme
>>
>> ...or something along those lines.
>>
>>
>>> Or maybe global-ignores could be changed into a section by itself,
>>> just like auto-props is:
>>>
>>> [global-ignores]
>>> *.bak
>>> *.o
>>> *.lo
>>>
>>> I like this best, as this would have the advantage that it could
>>> then
>>> use exactly the same syntax as svn:ignore for setting the case
>>> sensitivity mode. Specifying global-ignores the "old" way would
>>> still
>>> be supported for backwards compatibility but would remain case-
>>> sensitive.
>>
>> Yup.
>>
>> Erik, I don't think this discussion is moot. There *are* things
>> we can
>> do here. It may be that for some reason we decide to do nothing,
>> but
>> compatibility concerns need not force the decision, fortunately.
>
> Ok. Assuming that you'd want the same for global-ignores, how does
> this proposal map to global-ignores (which is only a single line!)?
How about my proposal, which you quoted above, that global-ignores
become multiline (while retaining the existing single-line format for
backwards-compatibility but without the enhancements we're talking
about now)?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
> > I agree with Karl that such a line is highly unlikely to be used in
> > existing ignore rules such that it should not affect backward
> > compatibility in practice.
> >
> > http://svn.haxx.se/users/archive-2008-03/0781.shtml
>
> Agreed, and if we were still worried about compatibility, we'd just
> start such meta-syntactic lines with "/", like
>
> / option: case-insensitive
> *.txt
> *.obj
> / option: case-sensitive
> readme
>
> ...or something along those lines.
>
>
> > Or maybe global-ignores could be changed into a section by itself,
> > just like auto-props is:
> >
> > [global-ignores]
> > *.bak
> > *.o
> > *.lo
> >
> > I like this best, as this would have the advantage that it could then
> > use exactly the same syntax as svn:ignore for setting the case
> > sensitivity mode. Specifying global-ignores the "old" way would still
> > be supported for backwards compatibility but would remain case-
> > sensitive.
>
> Yup.
>
> Erik, I don't think this discussion is moot. There *are* things we can
> do here. It may be that for some reason we decide to do nothing, but
> compatibility concerns need not force the decision, fortunately.
Ok. Assuming that you'd want the same for global-ignores, how does
this proposal map to global-ignores (which is only a single line!)?
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
Ryan Schmidt <su...@ryandesign.com> writes:
> On Mar 24, 2008, at 15:18, Erik Huelsmann wrote:
>> I'd like to point out all this discussion is moot: the current
>> interface for svn:ignore doesn't allow for case-insensitive patterns
>> other than the glob ones already provided.
>>
>> The svn:ignore property is a public interface, meaning that we can't
>> change it until 2.0. Adding more properties which 'do almost the same'
>> is definitely out of line with anything the Subversion developers have
>> done so far and probably only serves to confuse.
>
> Not *all* this discussion is moot... There have been several
> suggestions in this thread which could be implemented without
> breaking backward compatibility.
What Ryan said.
Plus a strategy that hasn't been discussed yet: using "/" as an escape
hatch, since "/" is meaningless in filename patterns (given that
Subversion and most platforms already reserve it as a path separator).
> For example, the suggestion of introducing a mode for ignores, which
> is set to case-sensitive by default, but which can be changed to case-
> insensitive by writing a line like "option: caseinsensitive" or
> "option: -casesensitive" or "option: casesensitive=no".
>
> http://svn.haxx.se/users/archive-2008-03/0780.shtml
>
> I agree with Karl that such a line is highly unlikely to be used in
> existing ignore rules such that it should not affect backward
> compatibility in practice.
>
> http://svn.haxx.se/users/archive-2008-03/0781.shtml
Agreed, and if we were still worried about compatibility, we'd just
start such meta-syntactic lines with "/", like
/ option: case-insensitive
*.txt
*.obj
/ option: case-sensitive
readme
...or something along those lines.
> Or maybe global-ignores could be changed into a section by itself,
> just like auto-props is:
>
> [global-ignores]
> *.bak
> *.o
> *.lo
>
> I like this best, as this would have the advantage that it could then
> use exactly the same syntax as svn:ignore for setting the case
> sensitivity mode. Specifying global-ignores the "old" way would still
> be supported for backwards compatibility but would remain case-
> sensitive.
Yup.
Erik, I don't think this discussion is moot. There *are* things we can
do here. It may be that for some reason we decide to do nothing, but
compatibility concerns need not force the decision, fortunately.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 24, 2008, at 15:18, Erik Huelsmann wrote:
> I'd like to point out all this discussion is moot: the current
> interface for svn:ignore doesn't allow for case-insensitive patterns
> other than the glob ones already provided.
>
> The svn:ignore property is a public interface, meaning that we can't
> change it until 2.0. Adding more properties which 'do almost the same'
> is definitely out of line with anything the Subversion developers have
> done so far and probably only serves to confuse.
Not *all* this discussion is moot... There have been several
suggestions in this thread which could be implemented without
breaking backward compatibility.
For example, the suggestion of introducing a mode for ignores, which
is set to case-sensitive by default, but which can be changed to case-
insensitive by writing a line like "option: caseinsensitive" or
"option: -casesensitive" or "option: casesensitive=no".
http://svn.haxx.se/users/archive-2008-03/0780.shtml
I agree with Karl that such a line is highly unlikely to be used in
existing ignore rules such that it should not affect backward
compatibility in practice.
http://svn.haxx.se/users/archive-2008-03/0781.shtml
The next trick is to find a solution for global-ignores, since it's
specified all on one line. Either devise a syntax for this option
argument that has no whitespace ("option:caseinsensitive"?) which can
thus be used in the global-ignores specification, or an additional
config option specifying whether global-ignores are case-sensitive
(default) or case-insensitive ("global-ignores-are-case-sensitive =
no"?) or an additional config option for specifying case-insensitive
global-ignores ("global-ignores-case-insensitive = *.bak"?) in
addition to the existing global-ignores key for case-sensitive matches.
Or maybe global-ignores could be changed into a section by itself,
just like auto-props is:
[global-ignores]
*.bak
*.o
*.lo
I like this best, as this would have the advantage that it could then
use exactly the same syntax as svn:ignore for setting the case
sensitivity mode. Specifying global-ignores the "old" way would still
be supported for backwards compatibility but would remain case-
sensitive.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On Mon, Mar 24, 2008 at 9:09 PM, Reedick, Andrew <jr...@att.com> wrote:
>
> > -----Original Message-----
> > From: Jared Hardy [mailto:jaredhardy@gmail.com]
> > Sent: Monday, March 24, 2008 3:25 PM
> > To: users@subversion.tigris.org
> > Subject: Re: Ignore patterns should not be case sensitive (usability)
> >
> >
> > While I like the amusing subtlety of the suggestion here, I think a
> > lot of this discussion is ignoring the basics of good interface
> > design. Useful defaults are very important to all interfaces, even
> > command-line tools -- especially when appealing to a broad user base.
> > Most (if not all) users try to avoid files having the same name with
> > mixed case, and by the same token don't think about case when writing
> > comparison rules. In Windows, they don't even really have a choice in
> > the matter, so all features that favor case-insensitivity there should
> > be enabled at all times, regardless of user preference. Even in my
> > C/++ programming, I tend towards case-insensitive string comparison
> > routines by default. Forcing humans to be that consistent, about
> > something as subtle as case, is just a fool's errand.
> > So, I'm obviously biased here, maybe in part from dealing with
> > artists as my primary users. I just tend to think case-insensitivity
> > should be the default for ALL user facing string operations,
> > especially with something as arbitrary as file names.
> >
>
>
> I would have to agree with case insensitive globs/regexes by default.
> Subversion is OS independent, so why should it favor one OS's paradigm
> over another? Given how we frequently we throw out the mantra "it's a
> social problem, not a tool problem," it would make sense to choose 'case
> insensitive' globs/regexes by default, since that would favor average
> humans.
I'd like to point out all this discussion is moot: the current
interface for svn:ignore doesn't allow for case-insensitive patterns
other than the glob ones already provided.
The svn:ignore property is a public interface, meaning that we can't
change it until 2.0. Adding more properties which 'do almost the same'
is definitely out of line with anything the Subversion developers have
done so far and probably only serves to confuse.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Ignore patterns should not be case sensitive (usability)
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Jared Hardy [mailto:jaredhardy@gmail.com]
> Sent: Monday, March 24, 2008 3:25 PM
> To: users@subversion.tigris.org
> Subject: Re: Ignore patterns should not be case sensitive (usability)
>
>
> While I like the amusing subtlety of the suggestion here, I think a
> lot of this discussion is ignoring the basics of good interface
> design. Useful defaults are very important to all interfaces, even
> command-line tools -- especially when appealing to a broad user base.
> Most (if not all) users try to avoid files having the same name with
> mixed case, and by the same token don't think about case when writing
> comparison rules. In Windows, they don't even really have a choice in
> the matter, so all features that favor case-insensitivity there should
> be enabled at all times, regardless of user preference. Even in my
> C/++ programming, I tend towards case-insensitive string comparison
> routines by default. Forcing humans to be that consistent, about
> something as subtle as case, is just a fool's errand.
> So, I'm obviously biased here, maybe in part from dealing with
> artists as my primary users. I just tend to think case-insensitivity
> should be the default for ALL user facing string operations,
> especially with something as arbitrary as file names.
>
I would have to agree with case insensitive globs/regexes by default.
Subversion is OS independent, so why should it favor one OS's paradigm
over another? Given how we frequently we throw out the mantra "it's a
social problem, not a tool problem," it would make sense to choose 'case
insensitive' globs/regexes by default, since that would favor average
humans.
Besides, if you know about case sensitivity, then you're smart enough to
look for and use a case sensitive flag. Anyone who isn't already aware
of case sensitivity wouldn't know why their glob/regex was failing and
wouldn't know what to do.
Version control doesn't make money, it saves money. So, the less you
spend on training, the more value SVN has.
(Just to be clear: filenames should remain case sensitive because
there's no good compromise. Regex/blobs should be insensitive by
default.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Jared Hardy wrote:
>> Well, no... that was because this http://en.wikipedia.org/wiki/ASR33
>> only had an uppercase ASCII character set.
>
> Wow -- this just proves how twisted your mind is, by your CS
> background. This is exactly why you shouldn't be trusted with human
> interface design. ;)
Agreed, but as long as my bourne-compatible shell doesn't quietly accept
if [ "a" != "A" ]
then echo "They are totally different"
fi
a wise human won't ignore the difference either when working with computers.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Jared Hardy <ja...@gmail.com>.
On Mon, Mar 24, 2008 at 3:28 PM, Les Mikesell <le...@gmail.com> wrote:
> Jared Hardy wrote:
> > On Mon, Mar 24, 2008 at 1:47 PM, Les Mikesell <le...@gmail.com> wrote:
> >> I think I'm being realistic. Ignoring the case in filenames is about
> >> the same as ignoring the colors of a traffic light.
> >
> > I hate to quibble over such small things, but I must disagree with
> > this statement. Different character cases in strings are much more
> > like the difference between red and magenta (if you want to use the
> > color analogy).
>
> Not when they hit a case sensitive filesystem. There, they are simply
> different characters.
No, they are not. They are the same characters, in a different *state*
-- lower vs. caps state. That state is inherently ambiguous in common
use, and thus harder to perceive, than truly separate characters.
Depending on choice of font, even completely separate characters, with
separate common uses, LOOK the same: [1 l i I]. I'm talking about
humans here -- human perception, which is central to any interface
design. I don't care about filesystems -- that's a technical back-end
detail that users shouldn't be forced to contend with. This is about
the human interface, not the filesystem, nor any other back-end
detail.
> > In different contexts, those two colors can appear to
> > be exactly the same. It's only when you stack them directly on top of
> > each other, in the same (flat) lighting conditions, that the
> > differences become more apparent.
>
> This is precisely why the person using them needs to more sensitive to
> the difference, not encouraged to ignore it.
I'm not saying they should ignore it in every case. I'm just
acknowledging that humans do that by default -- none of your interface
defaults are going to change that fact, so they might as well
accommodate it, when technically feasible. In this case, I am speaking
for SVN 2.0 now, since Erik made it clear it's probably not feasible
for existing 1.x deployments.
> > Text case does not represent the same contrast -- it is
> > highly contextual. It's the same reason some pre-Internet grandparents
> > seem to have a tendency to keep the caps-lock on, and SHOUT at
> > everyone, in forums or e-mail. They don't see the difference, at all.
>
> Well, no... that was because this http://en.wikipedia.org/wiki/ASR33
> only had an uppercase ASCII character set.
Wow -- this just proves how twisted your mind is, by your CS
background. This is exactly why you shouldn't be trusted with human
interface design. ;) I assure you none of my parents or grandparents,
at least not the ones prone to SHOUT case, have ever used an ASR-33
Teletype, nor would they even know what that is. Even on old
mechanical typewriters, caps-lock was a convenience for those who
didn't care about case, not a technical requirement.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Jared Hardy wrote:
> On Mon, Mar 24, 2008 at 1:47 PM, Les Mikesell <le...@gmail.com> wrote:
>> I think I'm being realistic. Ignoring the case in filenames is about
>> the same as ignoring the colors of a traffic light.
>
> I hate to quibble over such small things, but I must disagree with
> this statement. Different character cases in strings are much more
> like the difference between red and magenta (if you want to use the
> color analogy).
Not when they hit a case sensitive filesystem. There, they are simply
different characters.
> In different contexts, those two colors can appear to
> be exactly the same. It's only when you stack them directly on top of
> each other, in the same (flat) lighting conditions, that the
> differences become more apparent.
This is precisely why the person using them needs to more sensitive to
the difference, not encouraged to ignore it. If you aren't aware of the
difference and the consequences you'll have a disaster when you move to
a platform where it matters, creating files that don't match their
references going one way or overwriting files with another's contents
going the other.
> Traffic lights were intentionally designed with the greatest
> possible contrast. Even then, to accomadate the color-blind members of
> human society, they had to standardize the regular spatial separation
> and relative positions (spaced, vertical), to be perceived properly in
> general. Text case does not represent the same contrast -- it is
> highly contextual. It's the same reason some pre-Internet grandparents
> seem to have a tendency to keep the caps-lock on, and SHOUT at
> everyone, in forums or e-mail. They don't see the difference, at all.
Well, no... that was because this http://en.wikipedia.org/wiki/ASR33
only had an uppercase ASCII character set.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Jared Hardy <ja...@gmail.com>.
On Mon, Mar 24, 2008 at 1:47 PM, Les Mikesell <le...@gmail.com> wrote:
> I think I'm being realistic. Ignoring the case in filenames is about
> the same as ignoring the colors of a traffic light.
I hate to quibble over such small things, but I must disagree with
this statement. Different character cases in strings are much more
like the difference between red and magenta (if you want to use the
color analogy). In different contexts, those two colors can appear to
be exactly the same. It's only when you stack them directly on top of
each other, in the same (flat) lighting conditions, that the
differences become more apparent.
Traffic lights were intentionally designed with the greatest
possible contrast. Even then, to accomadate the color-blind members of
human society, they had to standardize the regular spatial separation
and relative positions (spaced, vertical), to be perceived properly in
general. Text case does not represent the same contrast -- it is
highly contextual. It's the same reason some pre-Internet grandparents
seem to have a tendency to keep the caps-lock on, and SHOUT at
everyone, in forums or e-mail. They don't see the difference, at all.
In their darkly lit room, they think their magenta slippers are red.
;) Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Jared Hardy wrote:
>
>>
>> Yes, you are biased. It is absolutely wrong to not be aware of the
>> difference, especially in filenames and the problems it causes in a
>> mixed-platform world.
>
> You seem to be very biased as well, just with less admission.
I think I'm being realistic. Ignoring the case in filenames is about
the same as ignoring the colors of a traffic light.
> I'm not
> arguing that it's right not to be *aware* of the difference, at least
> not in all cases. I just think it's a valid assumption, that the
> interface should by default take into account the perceptions of the
> average user -- label case does not provide a sufficient difference in
> object definition to be noteworthy.
In this instance you might be right, but training people to ignore the
difference in general is like teaching them to ignore the colors of
traffic lights.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Jared Hardy <ja...@gmail.com>.
On Mon, Mar 24, 2008 at 12:44 PM, Les Mikesell <le...@gmail.com> wrote:
> Jared Hardy wrote:
> > While I like the amusing subtlety of the suggestion here, I think a
> > lot of this discussion is ignoring the basics of good interface
> > design.
>
> Err... you mean repeatable, reusable, consistent patterns instead of a
> gazillion special case exceptions?
No, I mean starting with the basic reasonable assumptions in the
defaults (like case insensitivity), and adding options for the more
rare exceptions from there.
> > Useful defaults are very important to all interfaces, even
> > command-line tools -- especially when appealing to a broad user base.
> > Most (if not all) users try to avoid files having the same name with
> > mixed case, and by the same token don't think about case when writing
> > comparison rules.
>
> I think you mean users who only have experience on only one platform here.
No, I mean humans. I could care less about what platforms those humans
are using at any given time. Most people I talk to do NOT think these
files would be likely to have any different content or meaning, no
matter what their technical background is:
title.txt
Title.txt
title.TXT
...
That is regardless of platform.
> > In Windows, they don't even really have a choice in
> > the matter, so all features that favor case-insensitivity there should
> > be enabled at all times, regardless of user preference. Even in my
> > C/++ programming, I tend towards case-insensitive string comparison
> > routines by default. Forcing humans to be that consistent, about
> > something as subtle as case, is just a fool's errand.
>
> But absolutely necessary if you ever have any hope of escaping your
> single-platform trap.
Again, my admittedly biased views are regardless of platform. I
actually think allowing the confusion of matching mixed case, in
something that is expected to be interpreted by humans, like file
names and paths, is a huge mistake on ANY platform. It's one of the
few problems I have left with POSIX environments in general. Even in
something as technical as programming, if I saw any code labeling
separate functions (or worse, classes) with the same name but
different case, I would strongly suspect the author of intentional
obfuscation. There is no valid technical reason to require such
confusing labels.
> > So, I'm obviously biased here, maybe in part from dealing with
> > artists as my primary users. I just tend to think case-insensitivity
> > should be the default for ALL user facing string operations,
> > especially with something as arbitrary as file names.
>
> Yes, you are biased. It is absolutely wrong to not be aware of the
> difference, especially in filenames and the problems it causes in a
> mixed-platform world.
You seem to be very biased as well, just with less admission. I'm not
arguing that it's right not to be *aware* of the difference, at least
not in all cases. I just think it's a valid assumption, that the
interface should by default take into account the perceptions of the
average user -- label case does not provide a sufficient difference in
object definition to be noteworthy.
Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Jared Hardy wrote:
> On Mon, Mar 24, 2008 at 11:51 AM, Les Mikesell <le...@gmail.com> wrote:
>> Karl Fogel wrote:
>> > "John M. Black" <jo...@gmail.com> writes:
>> >> [...]
>> >>
>> >> Please consider making Ignore pattern-matching case insensitive.
>> >>
>> >> OR at the very least, let the user choose. Maybe the easiest way to
>> >> do this is to keep the current Ignore property intact, and add a new
>> >> property "svn:ignoreNoCase". That way users can have it either way
>> >> for any item.
>> >
>> > How about a new property, "svn:Ignore", that means...
>> >
>> > Okay, sorry, bad joke.
>>
>> Actually I think it would make perfect sense to make mixed case in the
>> property name trigger case insensitivity in handling its values wherever
>> that would have any meaning. Unless you already have inconsistent
>> handling and accept mixed case names.
>
> While I like the amusing subtlety of the suggestion here, I think a
> lot of this discussion is ignoring the basics of good interface
> design.
Err... you mean repeatable, reusable, consistent patterns instead of a
gazillion special case exceptions?
> Useful defaults are very important to all interfaces, even
> command-line tools -- especially when appealing to a broad user base.
> Most (if not all) users try to avoid files having the same name with
> mixed case, and by the same token don't think about case when writing
> comparison rules.
I think you mean users who only have experience on only one platform here.
> In Windows, they don't even really have a choice in
> the matter, so all features that favor case-insensitivity there should
> be enabled at all times, regardless of user preference. Even in my
> C/++ programming, I tend towards case-insensitive string comparison
> routines by default. Forcing humans to be that consistent, about
> something as subtle as case, is just a fool's errand.
But absolutely necessary if you ever have any hope of escaping your
single-platform trap.
> So, I'm obviously biased here, maybe in part from dealing with
> artists as my primary users. I just tend to think case-insensitivity
> should be the default for ALL user facing string operations,
> especially with something as arbitrary as file names.
Yes, you are biased. It is absolutely wrong to not be aware of the
difference, especially in filenames and the problems it causes in a
mixed-platform world.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 24, 2008, at 18:43, Steve Sisak wrote:
> Another sane choice would be to default to insensitive with an
> option to force sensitivity.
But that change is not backward-compatible. Currently the default is
case-sensitive and it needs to stay that way for Subversion's
backward-compatibility guarantee.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Steve Sisak <sg...@codewell.com>.
At 4:10 PM -0500 3/24/08, Les Mikesell wrote:
>Steve Sisak wrote:
>>
>>Perhaps what you really want is for ignore patters to obey the
>>semantics of the file system where the is stored by default.
>
>What would that mean in the context of working copies checked out in
>different environments?
I would assume that glob expressions would obey the semantics of the
environment where the working copy was checked out:
The question is wether you use the requirement that the glob
expression match the file name or the file name match the glob
expressions.
I just checked and the Mac OS X terminal these are not equivalent --
glob expressions are case sensitive even on a non-case sensitive file
system:
sgs$ echo this is foo > foo.txt
sgs$ echo this is BAR > BAR.TXT
sgs$ ls
BAR.TXT foo.txt
sgs$ ls *.TXT
BAR.TXT
sgs$ ls *.txt
foo.txt
sgs$ ls foo.txt
foo.txt
sgs$ ls bar.txt
bar.txt
sgs$ cat foo.txt
this is foo
sgs$ cat bar.txt
this is BAR
sgs$
But note that the last "cat" succeeds because the file system is case
insensitive.
Not sure which obeys the "principal of least user astonishment", but
I'm leaning toward obeying the semantics of the filesystem where the
working copy is checked out.
Another sane choice would be to default to insensitive with an option
to force sensitivity.
YMMV,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Steve Sisak wrote:
>
> Perhaps what you really want is for ignore patters to obey the semantics
> of the file system where the is stored by default.
What would that mean in the context of working copies checked out in
different environments?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Andy Levy <an...@gmail.com>.
On Mon, Mar 24, 2008 at 3:43 PM, Steve Sisak <sg...@codewell.com> wrote:
> While we're at it, it might also be worthwhile to have a way to
> specify that a repository should be case-insensitive so that the user
> gets a warning if they try to check in a file differing only in case
> from an existing file (although move should be allowed to change the
> canonical capitalization).
There already is a hook script which will reject a commit in this
case. http://subversion.tigris.org/tools_contrib.html#hook_scripts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Steve Sisak <sg...@codewell.com>.
At 12:25 PM -0700 3/24/08, Jared Hardy wrote:
>On Mon, Mar 24, 2008 at 11:51 AM, Les Mikesell <le...@gmail.com> wrote:
>> Karl Fogel wrote:
> > > "John M. Black" <jo...@gmail.com> writes:
> > >>
>> >> Please consider making Ignore pattern-matching case insensitive.
>> >>
>> >> OR at the very least, let the user choose. Maybe the easiest way to
>> >> do this is to keep the current Ignore property intact, and add a new
>> >> property "svn:ignoreNoCase". That way users can have it either way
>> >> for any item.
>> >
>> > How about a new property, "svn:Ignore", that means...
>> >
>> > Okay, sorry, bad joke.
>>
>> Actually I think it would make perfect sense to make mixed case in the
>> property name trigger case insensitivity in handling its values wherever
>> that would have any meaning. Unless you already have inconsistent
>> handling and accept mixed case names.
>
>While I like the amusing subtlety of the suggestion here, I think a
>lot of this discussion is ignoring the basics of good interface
>design. Useful defaults are very important to all interfaces, even
>command-line tools -- especially when appealing to a broad user base.
>Most (if not all) users try to avoid files having the same name with
>mixed case, and by the same token don't think about case when writing
>comparison rules. In Windows, they don't even really have a choice in
>the matter, so all features that favor case-insensitivity there should
>be enabled at all times, regardless of user preference.
Mac OS X (HFS+) presents an even more interesting case:
Case sensitivity is on a volume-by-volume basis, depending on how the
user chose to format the volume (HFS, HFS+, HFS+ Case-sensitive,
FAT32, UFS).
All API's use unicode for file names -- and HFS+ stores unicode names
in decomposed form and can be either case sensitive or case
preserving (but insensitive).
Perhaps what you really want is for ignore patters to obey the
semantics of the file system where the is stored by default.
While we're at it, it might also be worthwhile to have a way to
specify that a repository should be case-insensitive so that the user
gets a warning if they try to check in a file differing only in case
from an existing file (although move should be allowed to change the
canonical capitalization).
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Jared Hardy <ja...@gmail.com>.
On Mon, Mar 24, 2008 at 11:51 AM, Les Mikesell <le...@gmail.com> wrote:
> Karl Fogel wrote:
> > "John M. Black" <jo...@gmail.com> writes:
> >> [...]
> >>
> >> Please consider making Ignore pattern-matching case insensitive.
> >>
> >> OR at the very least, let the user choose. Maybe the easiest way to
> >> do this is to keep the current Ignore property intact, and add a new
> >> property "svn:ignoreNoCase". That way users can have it either way
> >> for any item.
> >
> > How about a new property, "svn:Ignore", that means...
> >
> > Okay, sorry, bad joke.
>
> Actually I think it would make perfect sense to make mixed case in the
> property name trigger case insensitivity in handling its values wherever
> that would have any meaning. Unless you already have inconsistent
> handling and accept mixed case names.
While I like the amusing subtlety of the suggestion here, I think a
lot of this discussion is ignoring the basics of good interface
design. Useful defaults are very important to all interfaces, even
command-line tools -- especially when appealing to a broad user base.
Most (if not all) users try to avoid files having the same name with
mixed case, and by the same token don't think about case when writing
comparison rules. In Windows, they don't even really have a choice in
the matter, so all features that favor case-insensitivity there should
be enabled at all times, regardless of user preference. Even in my
C/++ programming, I tend towards case-insensitive string comparison
routines by default. Forcing humans to be that consistent, about
something as subtle as case, is just a fool's errand.
So, I'm obviously biased here, maybe in part from dealing with
artists as my primary users. I just tend to think case-insensitivity
should be the default for ALL user facing string operations,
especially with something as arbitrary as file names.
;) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Karl Fogel wrote:
> "John M. Black" <jo...@gmail.com> writes:
>> [...]
>>
>> Please consider making Ignore pattern-matching case insensitive.
>>
>> OR at the very least, let the user choose. Maybe the easiest way to
>> do this is to keep the current Ignore property intact, and add a new
>> property "svn:ignoreNoCase". That way users can have it either way
>> for any item.
>
> How about a new property, "svn:Ignore", that means...
>
> Okay, sorry, bad joke.
Actually I think it would make perfect sense to make mixed case in the
property name trigger case insensitivity in handling its values wherever
that would have any meaning. Unless you already have inconsistent
handling and accept mixed case names.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Kevin Grover <ke...@kevingrover.net>.
On Fri, Mar 21, 2008 at 10:36 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "John M. Black" <jo...@gmail.com> writes:
> > [...]
>
> >
> > Please consider making Ignore pattern-matching case insensitive.
> >
> > OR at the very least, let the user choose. Maybe the easiest way to
> > do this is to keep the current Ignore property intact, and add a new
> > property "svn:ignoreNoCase". That way users can have it either way
> > for any item.
>
> How about a new property, "svn:Ignore", that means...
>
> Okay, sorry, bad joke.
>
> We could use an extra property, like you say, or a run-time
> configuration option, or both. The run-time option is probably easiest
> to implement. Would it be a compatibility break to have that option
> turned on by default (given that a user could always turn it off)? I
> don't know.
>
> Another possibility: be case-insensitive just for patterns of the form
> "*.foo", which probably covers more than 90% of the use cases.
>
> I'm just tossing out ideas here. At some point, we should take this
> thread to dev@, and see if we can get consensus on a solution. I do see
> your point about how the current behavior is (usually) not great.
>
> -Karl
>
How about adding configuration options to svn:ignore? Like .hgignore
does for setting the syntax.
eg.
--------------------------- .hgignore
# use glob syntax.
syntax: glob
*.elc
*.pyc
*~
.*.swp
# switch to regexp syntax.
syntax: regexp
^\.pc/
--------------------------- .hgignore
SVN could have an option:
option: [+-]casesensative
Where +casentative is the default option (and this maintains comapitility.
If this could potentially break current properties lists, there could
be another svn:ignore-options where these were set.
In the processes, couldn't '# blah...' be allowed as comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"John M. Black" <jo...@gmail.com> writes:
> [...]
>
> Please consider making Ignore pattern-matching case insensitive.
>
> OR at the very least, let the user choose. Maybe the easiest way to
> do this is to keep the current Ignore property intact, and add a new
> property "svn:ignoreNoCase". That way users can have it either way
> for any item.
How about a new property, "svn:Ignore", that means...
Okay, sorry, bad joke.
We could use an extra property, like you say, or a run-time
configuration option, or both. The run-time option is probably easiest
to implement. Would it be a compatibility break to have that option
turned on by default (given that a user could always turn it off)? I
don't know.
Another possibility: be case-insensitive just for patterns of the form
"*.foo", which probably covers more than 90% of the use cases.
I'm just tossing out ideas here. At some point, we should take this
thread to dev@, and see if we can get consensus on a solution. I do see
your point about how the current behavior is (usually) not great.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "John M. Black" <jo...@gmail.com>.
> <rant>I'm in favor of keeping flexibility. I'm not in favor of
> dumbing down the current functionality to account for GUI-based users
> that do not have experience with globs. All the new languages have
> regexp libraries! </rant>
<rantResponse>I'm challenging this group to ask itself - who do you want SVN
to be for? If your goal is to only please the hardcore programmer
community, then why even bother having the TSVN client? You must realize
that SVN is now becoming a mainstream product, and that's a GOOD thing! But
it also means that the techie who loves command lines and blobs is no longer
your only audience.
There are just as many people in our company that rely on SVN that are no
more technically inclined than MS Word, as there are developers who don't
mind the complex syntax. Are you saying that the people in the first group
should *stop* using SVN? It's "not for them"? How dare this new customer
base infringe upon my little SVN world?</rantResponse>
Disclaimer: I do consider myself a hardcore programmer and myself don't
mind the command line and blobs (now that I know about them.) I'm simply
trying to represent the other side of the argument for some of my less
technically-inclined colleagues where I work.
> If it confuses some TSVN users, perhaps TSVN could add an 'ignore'
> wizard that allowed the user to select options (including a
> case-insensitive flag) and then generates the correct glob. (NOTE: I
> use TSVN heavily --- I seriously miss it when doing Linux development)
This is a really, really good idea. Should I bring the discussion there?
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
Forwarding to list and adding own comments.
2008/3/24, Kevin Grover <ke...@kevingrover.net>:
> On Sun, Mar 23, 2008 at 9:58 AM, Henrik Sundberg <st...@gmail.com> wrote:
> > 2008/3/23, Karl Fogel <kf...@red-bean.com>:
> > > "Henrik Sundberg" <st...@gmail.com> writes:
> > > > 2008/3/23, Karl Fogel <kf...@red-bean.com>:
> > > >> You know, one solution here could be that Tortoise translates the
> > > >> patterns for the user. You enter "*.txt", but Tortoise turns that into
> > > >> "*.[tT][xX][tT]" on the way to Subversion. (The delightful fact that
> > > >> Tortoise internally would then have a regexp to match a globbing pattern
> > > >> is a bonus.)
> > > >>
> > > >> In fact, the more I think about it, the more I like this. The svn
> > > >> libraries should continue to offer what they offer now, which is maximum
> > > >> control, so that those few who want case-sensitivity can at least get
> > > >> it. Meanwhile, each client that *uses* those libraries can decide what
> > > >> actually works best for its users. The command-line client would
> > > >> probably not translate, since its users are likely to know about
> > > >> globbing. But Tortoise can and, IMHO, should translate, because its
> > > >> users a) generally don't know about globs, and b) are accustomed to a
> > > >> case-insensitive environment anyway.
> > > >>
> > > >> Thoughts?
> > > >
> > > > I believe that would lead to problems. We're using both Linux and
> > > > Windows/Tortoise, for the same repository. Different handling of
> > > > auto-props for different users will end up in errors.
> > >
> > >
> > > Yes, but the current way leads to problems too. Which problems are
> > > worse?
> >
> > You don't need to choose between those two alternatives.
> > A global switch for case sensitivity might suffice. Or a changed syntax, eg:
> > *.txt ~= xxx is case insensitive.
> > Or add more sections, like [case-insensitive-auto-props].
> > That would allow more elaborate extensions as well. You'd be able to
> > add [first-match-auto-props] allowing special cases to be handled
> > first like
> > ReadMe.txt = xxx
> > *.txt = yyy
> >
> > A better way would probably be to add a few options like
> > "case-insensitive", "ordered", "regexp" and allow several [auto-props]
> > sections. Each section should be handled according to the currently
> > set options.
> > This would be both completely backwards compatible and easy to grasp.
> > /$
> >
>
>
> This is really a reply to all previous posts ...
>
> <rant>I'm in favor of keeping flexibility. I'm not in favor of
> dumbing down the current functionality to account for GUI-based users
> that do not have experience with globs. All the new languages have
> regexp libraries! </rant>
>
> If it confuses some TSVN users, perhaps TSVN could add an 'ignore'
> wizard that allowed the user to select options (including a
> case-insensitive flag) and then generates the correct glob. (NOTE: I
> use TSVN heavily --- I seriously miss it when doing Linux development)
>
> Personally, I would not mind having SVN support the 'syntax:
> glob/regexp' of hg. There are cases when the regexp is convenient.
> (for hg particularly so, because they extend into subdirectories).
> And, adding 'syntax: glob' or 'syntax: regexp' to the ignore list
> helps to self-document what the ignore least really means. If someone
> sees it and doesn't know what a glob is they can look it up.
>
> On case-insensitive operating systems, could the client just treat all
> ignores (even those from the global configuration) as
> case-insensitive? The users can not create file1.TXT and File1.txt
> files anyway, so why should they have to have multiple ignores?
> 'file1.txt' should catch them both. (as should 'File1.*' and '*.TXT')
> --- the ignores should be applied using the same rules as the OS to
> determine if a file 'matches'.
>
> I would strongly oppose specialized syntax (like adding ~ to the end),
> because it's just too confusing: those expressions could just as
> easily represent a real filename. I think it will confuse more people
> in the end because it will not be obvious, and it will not be what
> they'd expect.
>
> Having options
> option: [+-]case-insensitive
>
> Is more generic. And I think perhaps and more specific named option:
>
> case-sensitive: yes/no/auto
>
> Where yes could be any boolean yes (true, 1) and no could be false,0.
> 'auto' could be the default. Case-insensitive OS's would use
> case-insensitive compares, others would not. This would be what most
> people would expect. However, the options would exist to force the
> other behaviors.
I think auto is bad. Having a program generating .TMP files and auto
is used for the ignore pattern *.tmp, will lead to different behaviour
for Linux and Windows users of the program.
> Even more generic, extend the Hg syntax to allow case-insensitivity:
> syntax: glob|regexp [auto-sensitive|case-sensitive|case-insensitive]
>
> Another option would to be to steal a meta-syntax from something like Perl
>
> /*.txt/i
>
> Ignores all txt (case insensitive) text file (in glob mod). while
>
> /*\.txt$/i
>
> Does the same in regexp mode. Of course, if users are confused by
> globs (and don't know Perl), the confusion factor will have just
> increase exponentially.
I like this perl syntax. That would be enough for ignore patterns.
Is it good enough for auto-props as well?
I don't think it is enough to match the simple name for auto-props.
There are two problems:
1) I don't want the same handling for vendor code and my own code -> I
want to match the full path. How does perl handle '/' (like grep?)?
2) I want different handling in different repositories. The current
settings are global to the client -> I want to match the full URL or
the possibility to have different config-files for different
repositories. I'd like to be able to let the config file refer to the
config-file of the repository, making it possible for all users to use
the same values without the need of synchronization when the
configuration changes.
/$
> - Kevin
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/23, Karl Fogel <kf...@red-bean.com>:
> "Henrik Sundberg" <st...@gmail.com> writes:
> > 2008/3/23, Karl Fogel <kf...@red-bean.com>:
> >> You know, one solution here could be that Tortoise translates the
> >> patterns for the user. You enter "*.txt", but Tortoise turns that into
> >> "*.[tT][xX][tT]" on the way to Subversion. (The delightful fact that
> >> Tortoise internally would then have a regexp to match a globbing pattern
> >> is a bonus.)
> >>
> >> In fact, the more I think about it, the more I like this. The svn
> >> libraries should continue to offer what they offer now, which is maximum
> >> control, so that those few who want case-sensitivity can at least get
> >> it. Meanwhile, each client that *uses* those libraries can decide what
> >> actually works best for its users. The command-line client would
> >> probably not translate, since its users are likely to know about
> >> globbing. But Tortoise can and, IMHO, should translate, because its
> >> users a) generally don't know about globs, and b) are accustomed to a
> >> case-insensitive environment anyway.
> >>
> >> Thoughts?
> >
> > I believe that would lead to problems. We're using both Linux and
> > Windows/Tortoise, for the same repository. Different handling of
> > auto-props for different users will end up in errors.
>
>
> Yes, but the current way leads to problems too. Which problems are
> worse?
You don't need to choose between those two alternatives.
A global switch for case sensitivity might suffice. Or a changed syntax, eg:
*.txt ~= xxx is case insensitive.
Or add more sections, like [case-insensitive-auto-props].
That would allow more elaborate extensions as well. You'd be able to
add [first-match-auto-props] allowing special cases to be handled
first like
ReadMe.txt = xxx
*.txt = yyy
A better way would probably be to add a few options like
"case-insensitive", "ordered", "regexp" and allow several [auto-props]
sections. Each section should be handled according to the currently
set options.
This would be both completely backwards compatible and easy to grasp.
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Henrik Sundberg" <st...@gmail.com> writes:
> 2008/3/23, Karl Fogel <kf...@red-bean.com>:
>> You know, one solution here could be that Tortoise translates the
>> patterns for the user. You enter "*.txt", but Tortoise turns that into
>> "*.[tT][xX][tT]" on the way to Subversion. (The delightful fact that
>> Tortoise internally would then have a regexp to match a globbing pattern
>> is a bonus.)
>>
>> In fact, the more I think about it, the more I like this. The svn
>> libraries should continue to offer what they offer now, which is maximum
>> control, so that those few who want case-sensitivity can at least get
>> it. Meanwhile, each client that *uses* those libraries can decide what
>> actually works best for its users. The command-line client would
>> probably not translate, since its users are likely to know about
>> globbing. But Tortoise can and, IMHO, should translate, because its
>> users a) generally don't know about globs, and b) are accustomed to a
>> case-insensitive environment anyway.
>>
>> Thoughts?
>
> I believe that would lead to problems. We're using both Linux and
> Windows/Tortoise, for the same repository. Different handling of
> auto-props for different users will end up in errors.
Yes, but the current way leads to problems too. Which problems are
worse?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Henrik Sundberg <st...@gmail.com>.
2008/3/23, Karl Fogel <kf...@red-bean.com>:
> You know, one solution here could be that Tortoise translates the
> patterns for the user. You enter "*.txt", but Tortoise turns that into
> "*.[tT][xX][tT]" on the way to Subversion. (The delightful fact that
> Tortoise internally would then have a regexp to match a globbing pattern
> is a bonus.)
>
> In fact, the more I think about it, the more I like this. The svn
> libraries should continue to offer what they offer now, which is maximum
> control, so that those few who want case-sensitivity can at least get
> it. Meanwhile, each client that *uses* those libraries can decide what
> actually works best for its users. The command-line client would
> probably not translate, since its users are likely to know about
> globbing. But Tortoise can and, IMHO, should translate, because its
> users a) generally don't know about globs, and b) are accustomed to a
> case-insensitive environment anyway.
>
> Thoughts?
I believe that would lead to problems. We're using both Linux and
Windows/Tortoise, for the same repository. Different handling of
auto-props for different users will end up in errors.
/$
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 28, 2008, at 10:40, Erik Huelsmann wrote:
> Absolutely not: the client library knows exactly nothing about the
> client filesystem: it has no knowledge of which APIs to call, it
> doesn't know what the OS uses to encode its paths (in terms of
> character sets) and it doesn't know if the filesystem it's writing to
> is case-sensitive or not. And really, there's no reliable way to know:
> you can't assume on Unix the underlying filesystem is case-sensitive
> (think samba mounts backed by Windows) on a Linux box, nor can you
> assume case-insensitivity on Windows (think a network share backed by
> a Linux box).
First off: to the specific issue at hand, I agree that since
Subversion currently has only case-sensitive ignore patterns, it must
continue to have case-sensitive ignore patterns by default, even if a
case-insensitive option is offered. That's the backwards-
compatibility guarantee which must be maintained.
But just to nitpick the above, though I'm not a C programmer, I would
assume it is in fact possible to determine whether a given directory
lives on a case-sensitive filesystem or not. For example, can't you
1) make a temporary directory with a random name in the directory of
interest (mktemp -d)
2) make a file "foo" in the temporary directory and write a known
string into it
3) see if the file "FOO" now exists in the temporary directory and
contains the known string
If so, the directory is on a case-insensitive filesystem.
Subversion should be made to "play nice" with case-insensitive
filesystems. One issue I know of where Subversion doesn't play nice
is when you have a file "FOO" on disk and you say "svn add foo". On a
case-sensitive filesystem, the shell will say there is no file "foo"
and that's the end of it. But on a case-insensitive filesystem, the
user expects the file FOO to get added, but that's not exactly what
happens. Rather, Subversion sends the contents of the file FOO to the
repository but names it foo, which causes confusion in the working
copy and the filename's case to be recorded incorrectly in the
repository:
$ svnadmin create repo
$ REPO=file://`pwd`/repo
$ svn co $REPO wc
Checked out revision 0.
$ cd wc
$ touch FOO
$ svn add foo
A foo
$ svn ci -m ""
Adding foo
Transmitting file data .
Committed revision 1.
$ svn st
? FOO
! foo
$ ls
FOO
$ svn ls $REPO
foo
$
Sadly this problem has been known for almost six years; see
"Additional comments from William Uther Thu Jun 6 08:45:48 -0700
2002" here:
http://subversion.tigris.org/issues/show_bug.cgi?id=667
> To clarify: all OS specific code is encapsulated in the APR
> portability layer in order for Subversion code (including its client
> library) to stay platform independent.
If APR doesn't already have a function to determine if a directory is
on a case-sensitive filesystem, that would seem an ideal place to add
it, if it were needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Les Mikesell wrote:
> Anders J. Munch wrote:
> > You [Erik] prove my point. What you just wrote is a piece of knowledge about
> > client-side file systems. Knowledge like that is embedded in the
> > workings of Subversion.
>
> No, subversion just makes library and system calls. Any differences are
> up to the client system.
Now you're heading into an ontological debate that I don't intend to waste time on.
regards, Anders
Re: Ignore patterns should not be case sensitive (usability)
Posted by Les Mikesell <le...@gmail.com>.
Anders J. Munch wrote:
>> That makes no sense. Without knowledge of the client side
>> file system
>>> Subversion wouldn't be able to read and write files,
>> Why not? There are standard C library calls for this. It's possible to
>> write completely portable C code using the C library which reads and
>> writes files.
>>
>>> navigate directories etc.
>> Same here: readdir() and friends work on most platforms.
>
> You prove my point. What you just wrote is a piece of knowledge about
> client-side file systems. Knowledge like that is embedded in the
> workings of Subversion.
No, subversion just makes library and system calls. Any differences are
up to the client system.
> It just doesn't have a separate physical
> manifestation.
The physical manifestation is in the filesystem handling. I don't know
if windows has any internal filesystems with case-sensitivity, but it
might be working on a samba-mounted directory from another platform. OS
X, Linux and other unix-like systems can mount both case sensitive and
insensitive filesystems and applications won't know the difference.
They will happily overwrite file.txt with a different file.TXT when
running on a case insensitive file system.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Erik Huelsmann wrote:
> On 3/28/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> > That makes no sense. Without knowledge of the client side
> file system
> > Subversion wouldn't be able to read and write files,
>
> Why not? There are standard C library calls for this. It's possible to
> write completely portable C code using the C library which reads and
> writes files.
>
> > navigate directories etc.
>
> Same here: readdir() and friends work on most platforms.
You prove my point. What you just wrote is a piece of knowledge about
client-side file systems. Knowledge like that is embedded in the
workings of Subversion. It just doesn't have a separate physical
manifestation.
Similarly, you could say, using case-insensitive patterns but with
character sets case-sensitive works on most platforms. Structurally,
this is the same: there is no knowledge database in the program per
se; the knowledge is there but implicit in the design.
>[...]there are patterns to specify all case-variants on
> one line, although probably not the most readable, not extremely
> inefficient.
Which is exactly the same as would have been the case with Deven's
proposal, only the need for using the less readable (and less typable,
not everyone uses a US keyboard layout) forms would become much rarer
- on all platforms.
But if there's no support for it, I don't intend to argue it further,
so bye for now.
- Anders
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/28/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> Erik Huelsmann wrote:
> > > Either you don't change anything at all or you allow some
> > > propertionality in the burden of evidence.
> >
> > No. Because I know there are patterns which won't exist:
> >
> > /option: ...
>
> You don't know that because it isn't true. I can disprove it by
> counterexample.
>
> > >
> > > Ignore patterns are used for talking about client-side files,
> > > notably files that are not (yet) under Subversion's control.
> > > Consistency with client-side file system rules and conventions is
> > > what matters here.
> >
> > Subversion doesn't have knowledge of the client side file system and
> > as far as I can see, neither will it be able to grow any. So, since we
> > can't be consistent with the host platform, we'll have to be
> > consistent with ourselves (which is case-sensitive).
>
> That makes no sense. Without knowledge of the client side file system
> Subversion wouldn't be able to read and write files,
Why not? There are standard C library calls for this. It's possible to
write completely portable C code using the C library which reads and
writes files.
> navigate directories etc.
Same here: readdir() and friends work on most platforms. [Agreed,
Subversion needs more functionality than the standard C library
provides, but we have a different portability library to stay platform
independent anyway.]
> The subversion client library is to a large part a
> mediator layer between the repository server and the client side file
> system. It is positively loaded with knowledge and assumptions about
> the client-side file system.
Absolutely not: the client library knows exactly nothing about the
client filesystem: it has no knowledge of which APIs to call, it
doesn't know what the OS uses to encode its paths (in terms of
character sets) and it doesn't know if the filesystem it's writing to
is case-sensitive or not. And really, there's no reliable way to know:
you can't assume on Unix the underlying filesystem is case-sensitive
(think samba mounts backed by Windows) on a Linux box, nor can you
assume case-insensitivity on Windows (think a network share backed by
a Linux box).
To clarify: all OS specific code is encapsulated in the APR
portability layer in order for Subversion code (including its client
library) to stay platform independent.
> Subversion limits itself to using a portable subset of client side
> file system features, of course, so you can't exactly match the
> expectations of all platforms, because that would require a lot of
> platform-specific code. But what you can do is find a common path
> that works reasonable well with a wide variety of platforms, and
> indeed, isn't that what Subversion developers always have done?
Exactly! The common path on an extremely wide range of platforms is to
use case-sensitivity, because if you wouldn't use that, Subversion
wouldn't support a number of (rather significant) platforms [ie many
Unix platforms]. What you're arguing is that this is not what the user
expects, but it is what - from a technical point of view - works
'reasonably well': there are patterns to specify all case-variants on
one line, although probably not the most readable, not extremely
inefficient.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Karl Fogel wrote:
> "Anders J. Munch" <aj...@flonidan.dk> writes:
> >> No, what I am saying is that it's not merely mindnumbingly
> >> unlikely, but
> >> actually impossible -- because Subversion itself prohibits "/" in a
> >> filename, whether or not the client platform does.
> >
> > Subversion does not prohibit "/" in an ignore pattern.
>
> Yes, I know, but Subversion won't ever use that pattern, because it
> could never version a file matching that name, that's what I'm saying.
Which brings us right back to "mindnumbingly unlikely". Sorry, but I
got it right the first time, and I have no idea what your quarrel is.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Anders J. Munch" <aj...@flonidan.dk> writes:
>> No, what I am saying is that it's not merely mindnumbingly
>> unlikely, but
>> actually impossible -- because Subversion itself prohibits "/" in a
>> filename, whether or not the client platform does.
>
> Subversion does not prohibit "/" in an ignore pattern.
Yes, I know, but Subversion won't ever use that pattern, because it
could never version a file matching that name, that's what I'm saying.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Anders J. Munch" <aj...@flonidan.dk> writes:
>> Hey Anders, could you please give that example? I also thought (proper)
>> Subversion ignore patterns would never have a "/" in them, since
>> Subversion doesn't allow that character in filenames. If you have a
>> counter-example, that would be very educational for us.
>
> I was being facetious. Erik was playing the game of principles, laws
> and absolute truths, and in that spirit I manufactured a completely
> ineffectual ignore pattern containing a slash on my local system. In
> the real world I agree that /option is mindnumbingly unlikely to clash
> with anything. I can think of a few ways ignore patterns with slashes
> could come to be by accident, but that's all theoretical.
No, what I am saying is that it's not merely mindnumbingly unlikely, but
actually impossible -- because Subversion itself prohibits "/" in a
filename, whether or not the client platform does. This is a
deliberate, documented behavior of Subversion. So that's why we know
"/" is safe for meta-information.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Karl Fogel wrote:
> "Anders J. Munch" <aj...@flonidan.dk> writes:
> >> No. Because I know there are patterns which won't exist:
> >>
> >> /option: ...
> >
> > You don't know that because it isn't true. I can disprove it by
> > counterexample.
>
> Hey Anders, could you please give that example? I also thought (proper)
> Subversion ignore patterns would never have a "/" in them, since
> Subversion doesn't allow that character in filenames. If you have a
> counter-example, that would be very educational for us.
I was being facetious. Erik was playing the game of principles, laws
and absolute truths, and in that spirit I manufactured a completely
ineffectual ignore pattern containing a slash on my local system. In
the real world I agree that /option is mindnumbingly unlikely to clash
with anything. I can think of a few ways ignore patterns with slashes
could come to be by accident, but that's all theoretical.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"Anders J. Munch" <aj...@flonidan.dk> writes:
>> No. Because I know there are patterns which won't exist:
>>
>> /option: ...
>
> You don't know that because it isn't true. I can disprove it by
> counterexample.
Hey Anders, could you please give that example? I also thought (proper)
Subversion ignore patterns would never have a "/" in them, since
Subversion doesn't allow that character in filenames. If you have a
counter-example, that would be very educational for us.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Erik Huelsmann wrote:
> > Either you don't change anything at all or you allow some
> > propertionality in the burden of evidence.
>
> No. Because I know there are patterns which won't exist:
>
> /option: ...
You don't know that because it isn't true. I can disprove it by
counterexample.
> >
> > Ignore patterns are used for talking about client-side files,
> > notably files that are not (yet) under Subversion's control.
> > Consistency with client-side file system rules and conventions is
> > what matters here.
>
> Subversion doesn't have knowledge of the client side file system and
> as far as I can see, neither will it be able to grow any. So, since we
> can't be consistent with the host platform, we'll have to be
> consistent with ourselves (which is case-sensitive).
That makes no sense. Without knowledge of the client side file system
Subversion wouldn't be able to read and write files, navigate
directories etc. The subversion client library is to a large part a
mediator layer between the repository server and the client side file
system. It is positively loaded with knowledge and assumptions about
the client-side file system.
Subversion limits itself to using a portable subset of client side
file system features, of course, so you can't exactly match the
expectations of all platforms, because that would require a lot of
platform-specific code. But what you can do is find a common path
that works reasonable well with a wide variety of platforms, and
indeed, isn't that what Subversion developers always have done?
- Anders
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/28/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> Erik Huelsmann wrote:
> > On 3/27/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> > > Now, is there a practical problem? Do you know of any actual real
> > > life Subversion setups where widening the match of ignore patterns
> > > would cause breakage?
> >
> > That's not the issue: the question we have to answer is: do you know
> > that they *don't* exist?
>
> Indeed not. Nor does anyone know for sure that there are no ignore
> patterns in the wild of the form
> ^option: [a-z0-9]+
> I take it you reject that proposal on the same grounds?
Exactly.
> Either you don't change anything at all or you allow some
> propertionality in the burden of evidence.
No. Because I know there are patterns which won't exist:
/option: ...
is guaranteed not to exist: '/' can't be part of a file name.
> > Well, in that case we're free to change the implementation if
> > developers reach consensus. However, I think that any features we
> > implement in the system should at least be consistent with the system
> > itself and if possible - after that - consistent with the OSes it runs
> > on. Since Subversion itself is case-sensitive, I still argue that the
> > default should be case-sensitive.
>
> Ignore patterns are used for talking about client-side files, notably
> files that are not (yet) under Subversion's control. Consistency with
> client-side file system rules and conventions is what matters here.
Subversion doesn't have knowledge of the client side file system and
as far as I can see, neither will it be able to grow any. So, since we
can't be consistent with the host platform, we'll have to be
consistent with ourselves (which is case-sensitive).
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Erik Huelsmann wrote:
> On 3/27/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> > Now, is there a practical problem? Do you know of any actual real
> > life Subversion setups where widening the match of ignore patterns
> > would cause breakage?
>
> That's not the issue: the question we have to answer is: do you know
> that they *don't* exist?
Indeed not. Nor does anyone know for sure that there are no ignore
patterns in the wild of the form
^option: [a-z0-9]+
I take it you reject that proposal on the same grounds?
Either you don't change anything at all or you allow some
propertionality in the burden of evidence.
> Well, in that case we're free to change the implementation if
> developers reach consensus. However, I think that any features we
> implement in the system should at least be consistent with the system
> itself and if possible - after that - consistent with the OSes it runs
> on. Since Subversion itself is case-sensitive, I still argue that the
> default should be case-sensitive.
Ignore patterns are used for talking about client-side files, notably
files that are not (yet) under Subversion's control. Consistency with
client-side file system rules and conventions is what matters here.
regards, Anders
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/27/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> > > While not strictly 100% backwards compatible, I don't believe there's
> > > any real compatility issue. Anyone having a setup where lowercase
> > > means valuable source file, and uppercase means worthless build
> > > byproduct (or vice versa), has bigger problems than Subversion can
> > > solve.
> >
> > Is that so? Have you ever used Unix? With case-sensitive filesystems?
>
> Yes. I've seen .c/.C used to distinguish between C and C++. I've
> seen "makefile" and "Makefile" coexist to everyone's confusion. I
> understand the theoretical problem.
>
> Now, is there a practical problem? Do you know of any actual real
> life Subversion setups where widening the match of ignore patterns
> would cause breakage?
That's not the issue: the question we have to answer is: do you know
that they *don't* exist? Because if they do: we have a contract not to
change things.
> > I'm actually not all for changing the meaning of the current
> > interface: We even can't: it's a contract with our users we don't
> > change the meaning the interfaces until 2.0.
>
> Nor am I in any hurry to change anything.
Well, in that case we're free to change the implementation if
developers reach consensus. However, I think that any features we
implement in the system should at least be consistent with the system
itself and if possible - after that - consistent with the OSes it runs
on. Since Subversion itself is case-sensitive, I still argue that the
default should be case-sensitive.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
From: Erik Huelsmann [mailto:ehuels@gmail.com]
> > While not strictly 100% backwards compatible, I don't believe there's
> > any real compatility issue. Anyone having a setup where lowercase
> > means valuable source file, and uppercase means worthless build
> > byproduct (or vice versa), has bigger problems than Subversion can
> > solve.
>
> Is that so? Have you ever used Unix? With case-sensitive filesystems?
Yes. I've seen .c/.C used to distinguish between C and C++. I've
seen "makefile" and "Makefile" coexist to everyone's confusion. I
understand the theoretical problem.
Now, is there a practical problem? Do you know of any actual real
life Subversion setups where widening the match of ignore patterns
would cause breakage?
>
> I'm actually not all for changing the meaning of the current
> interface: We even can't: it's a contract with our users we don't
> change the meaning the interfaces until 2.0.
Nor am I in any hurry to change anything.
regards, Anders
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/27/08, Anders J. Munch <aj...@flonidan.dk> wrote:
> Deven T. Corzine wrote earlier in the thread:
> > my suggestion is to have bare letters in the pattern be
> > case-insensitive, but letters in character classes be case-sensitive.
> > This is a little funky, but it means that "*.txt" could match any case,
> > while "*.[t][x][t]" would only match the lower-case extension. It's a
> > little confusing to have differing case-sensitivity in different
> > contexts in the glob, but probably less confusing than the current
> > behavior, in the grand scheme of things.
>
> +1. Simple and flexible. No new syntax that I will never be able to
> remember, because months or years pass between each time I use it.
>
> While not strictly 100% backwards compatible, I don't believe there's
> any real compatility issue. Anyone having a setup where lowercase
> means valuable source file, and uppercase means worthless build
> byproduct (or vice versa), has bigger problems than Subversion can
> solve.
Is that so? Have you ever used Unix? With case-sensitive filesystems?
I'm actually not all for changing the meaning of the current
interface: We even can't: it's a contract with our users we don't
change the meaning the interfaces until 2.0.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Anders J. Munch" <aj...@flonidan.dk>.
Deven T. Corzine wrote earlier in the thread:
> my suggestion is to have bare letters in the pattern be
> case-insensitive, but letters in character classes be case-sensitive.
> This is a little funky, but it means that "*.txt" could match any case,
> while "*.[t][x][t]" would only match the lower-case extension. It's a
> little confusing to have differing case-sensitivity in different
> contexts in the glob, but probably less confusing than the current
> behavior, in the grand scheme of things.
+1. Simple and flexible. No new syntax that I will never be able to
remember, because months or years pass between each time I use it.
While not strictly 100% backwards compatible, I don't believe there's
any real compatility issue. Anyone having a setup where lowercase
means valuable source file, and uppercase means worthless build
byproduct (or vice versa), has bigger problems than Subversion can
solve.
regards, Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "Deven T. Corzine" <de...@ties.org>.
Karl Fogel wrote:
> Most of my patterns are extension-based: "*.foo" and the like. A few
> are explicit filenames, but I certainly agree that extensions are the
> common case.
>
My first inclination was to say that case-sensitivity was more
appropriate, because many filesystems are case-sensitive. (How does
Subversion handle case-insensitive local filesystems, by the way?)
Upon further reflection, it occurred to me that ignore patterns are a
generalization, and frequently used for extensions that identify the
file type, and the same extension/type relationship is likely to exist
without regard to case variations, which argues in favor of
case-insensitivity.
Since using a pattern like "*.[Tt][Xx][Tt]" is awkward and inconvenient,
harder to remember and use, and likely to be the preferred usage, I'll
take a page from Perl 6 design philosophy and suggest optimizing for the
common case (Huffman-coding style) while allowing the uncommon case --
my suggestion is to have bare letters in the pattern be
case-insensitive, but letters in character classes be case-sensitive.
This is a little funky, but it means that "*.txt" could match any case,
while "*.[t][x][t]" would only match the lower-case extension. It's a
little confusing to have differing case-sensitivity in different
contexts in the glob, but probably less confusing than the current
behavior, in the grand scheme of things.
Thoughts?
Deven
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
"John M. Black" <jo...@gmail.com> writes:
> Yes, but we should always have usability in mind for the average user. I had
> no idea about "globs", and even if I did RTFM, I'd find them extremely
> cumbersome. An otherwise user-friendly feature like Ignore shouldn't have a
> complex syntax to attain what is probably the 80% use case. Everyone
> understands simple wildcard syntax.
>
> Many of us here are comfortable with these kinds of syntaxes b/c we grew up on
> command lines, but remember that this feature also drives the Tortoise UI,
> whose users are not so technical. I opened this suggestion here after hearing
> this complaint from many others in our company that aren't techies and use
> Tortoise.
>
> Do any of you use Ignore for patterns that are not simple file extensions?
> (that's an honest question.)
Most of my patterns are extension-based: "*.foo" and the like. A few
are explicit filenames, but I certainly agree that extensions are the
common case.
You know, one solution here could be that Tortoise translates the
patterns for the user. You enter "*.txt", but Tortoise turns that into
"*.[tT][xX][tT]" on the way to Subversion. (The delightful fact that
Tortoise internally would then have a regexp to match a globbing pattern
is a bonus.)
In fact, the more I think about it, the more I like this. The svn
libraries should continue to offer what they offer now, which is maximum
control, so that those few who want case-sensitivity can at least get
it. Meanwhile, each client that *uses* those libraries can decide what
actually works best for its users. The command-line client would
probably not translate, since its users are likely to know about
globbing. But Tortoise can and, IMHO, should translate, because its
users a) generally don't know about globs, and b) are accustomed to a
case-insensitive environment anyway.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by "John M. Black" <jo...@gmail.com>.
On Sat, Mar 22, 2008 at 2:32 PM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:
> I think you are talking about the global-ignores in the config file?
> There you can use things like this:
> global-ignores = *.[tT][xX][tT]
> If you mean the svn:ignore property you can use the same thing there...
> They are descibed as globs in the documentation.
Yes, but we should always have usability in mind for the average user. I
had no idea about "globs", and even if I did RTFM, I'd find them extremely
cumbersome. An otherwise user-friendly feature like Ignore shouldn't have a
complex syntax to attain what is probably the 80% use case. Everyone
understands simple wildcard syntax.
Many of us here are comfortable with these kinds of syntaxes b/c we grew up
on command lines, but remember that this feature also drives the Tortoise
UI, whose users are not so technical. I opened this suggestion here after
hearing this complaint from many others in our company that aren't techies
and use Tortoise.
Do any of you use Ignore for patterns that are not simple file extensions?
(that's an honest question.)
-John
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Karl,
> Time for a test :-).
Sorry i didn't wrote that i tested it before i have written the
message...with svn:ignore as with global-ignores as well..
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Fogel <kf...@red-bean.com>.
Karl Heinz Marbaise <kh...@gmx.de> writes:
> If you mean the svn:ignore property you can use the same thing there...
Time for a test :-).
As the script below shows, globbing each letter works fine, so people
can just tweak today's ignore patterns to DTRT w.r.t. case.
---------------------------------------------------------------------------
#!/bin/sh
SVNDIR=/home/kfogel/src/subversion
SVN=${SVNDIR}/subversion/svn/svn
SVNADMIN=${SVNDIR}/subversion/svnadmin/svnadmin
URL=file:///`pwd`/repos
rm -rf repos wc import-me
${SVNADMIN} create repos
${SVN} co -q ${URL} wc
cd wc
${SVN} propset -q svn:ignore '*.[Tt][Xx][Tt]' .
touch foo.txt
touch FOO.TXT
touch foo.Txt
touch foo.tXt
touch This_should_be_the_only_file_shown---There_should_also_be_a_prop_mod
${SVN} st
cd ..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi John,
> However, making *Ignore patterns* case-sensitive is I think
> counterintuitive for this particular feature. The typical use case
> for Ignore is to ignore all files of a certain type, most of which
> will be encountered at some point in the future and don't exist yet.
> Can anyone think of a use case where a user or group of users would
> intentionally want to ignore .TXT files but not .txt or .Txt files?
I think you are talking about the global-ignores in the config file?
>
> Imagine trying to cover all the bases. You'd have to add:
> .TXT
> .TXt
> .TxT
> .tXT
> .Txt
> .tXt
> .txT
> .txt
There you can use things like this:
global-ignores = *.[tT][xX][tT]
If you mean the svn:ignore property you can use the same thing there...
They are descibed as globs in the documentation.
Kind regards
Karl Heinz Marbaise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Ignore patterns should not be case sensitive (usability)
Posted by Erik Huelsmann <eh...@gmail.com>.
On Fri, Mar 21, 2008 at 2:42 AM, John M. Black <jo...@gmail.com> wrote:
> (Before I begin, let me say this is *not* about the filesystem itself;
> I respect the current decision to keep filesystem operations
> case-sensitive.)
>
> However, making *Ignore patterns* case-sensitive is I think
> counterintuitive for this particular feature. The typical use case
> for Ignore is to ignore all files of a certain type, most of which
> will be encountered at some point in the future and don't exist yet.
> Can anyone think of a use case where a user or group of users would
> intentionally want to ignore .TXT files but not .txt or .Txt files?
>
> Imagine trying to cover all the bases. You'd have to add:
> .TXT
> .TXt
> .TxT
> .tXT
> .Txt
> .tXt
> .txT
> .txt
>
> I for one don't feel like entering every file extension 8 times.
Really? I thought they were globs, meaning this should work:
*.[tT][xX][tT]
Though probably not intuitive, it's one line instead of 8...
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org