Forwarding to list and adding own comments.
2008/3/24, Kevin Grover <kevin_at_kevingrover.net>:
> On Sun, Mar 23, 2008 at 9:58 AM, Henrik Sundberg <storangen_at_gmail.com> wrote:
> > 2008/3/23, Karl Fogel <kfogel_at_red-bean.com>:
> > > "Henrik Sundberg" <storangen_at_gmail.com> writes:
> > > > 2008/3/23, Karl Fogel <kfogel_at_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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-24 10:09:36 CET