gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: tla1.2 on cygwin


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: tla1.2 on cygwin
Date: Sat, 13 Mar 2004 15:02:37 -0800 (PST)


    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:
    > >     > From: Dustin Sallings <address@hidden>

    > >     >   We're talking about category and branch names belonging to 
individual 
    > >     > archives and colliding during collaboration, though.  

    > > Right.   And, that _is_ the insightful way to look at it that suggests
    > > (but does not compel) the conclusion that this an issue to address
    > > within arch.   You're hitting me where I live there.

    > > That's why, for example, I'm open to things like the ci-lint
    > > suggestion.

    > > However: re-ordering the patch-log tree order (for example) is:

    > > (a) fairly massively disruptive for users who don't care a whit
    > >     about this issue.

    > > (b) not a complete solution by any means nor a progressive step
    > >     towards a complete solution

    > Okay, as far as I can tell, the only complete solution is another level 
    > of indirection: present a case sensitive filesystem to tla by using a 
    > vu_ subsystem.  We should see if any of Lode's work applies here. 
    > Essentially,

    > 1. creating "CaseSensitive" should succeed, and record a mapping of 
    > "CaseSensitive -> CaseSensitive" somewhere
    > 2. creating "CaseSensitive" again should fail (because there's already a 
    > map entry for it).
    > 3. creating "casesensitive" should create a file called 
    > "casesensitive1", and record a mapping of casesensitive -> casesensitive1
    > 3. creating "casesensitive1" should create a file called 
    > casesensitive11, and record a mapping of casesensitive1 -> 
casesensitive11.

    > Naturally, all lookups would use the mapping.  The reason for using 
    > filesystem names similar to the vu name simply for user convenience.

    > Before using the mapping, it would have to be updated to reflect user 
    > changes to the filesystem.  The potential for user changes conflicting 
    > is low, since they're stuck with a case-insensitive filesystem.  They'd 
    > have to work hard to create a file name that conflicts with vu_ mapped 
name.


Oh sheesh.

I happen to think that "careful use" is a complete solution to this
problem.

It really, really is just like filenames used as Java classes, header
file names, tar file contents, etc.

If you put on blinders and try to think about this problem in
isolation then, yeah, you can spend endless afternoons dreaming up
application level solutions when really, a simple user-level
_convention_ is as close to a 100% solution as you're going to find.

The name mapping you suggest is cute but, of course, immediately falls
apart as soon as encountered by a tool that doesn't use vu_.

In other news -- I really shudder to think what happens when case
insensitive file systems meet Unicode.  Suddenly you're talking about
embedding a fairly complex case canonicalization algorithm based on
relatively huge data tables in every kernel and application that might
ever need to compare a filename.  And the end result is going to be
either locale dependent (uh... yeah, right) or linguistically
imperfect (uh.... what again were some thread contributors trying to
say about UI issues?  UIs should aim to make the truth intuitive --
they can't make the intuitive true.   If UIs could make the intuitive
true, then we wouldn't need science.)

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]