[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Ignore patterns should not be case sensitive (usability)

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Fri, 28 Mar 2008 16:40:11 +0100

On 3/28/08, Anders J. Munch <ajm_at_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_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-28 16:40:53 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.