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

[Tom Lord]

    > From: "David A. Wheeler" <address@hidden>

    > Here's an idea: why not reject making NEW categories, branches
    > (and maybe archives?) with the uppercase letters A-Z, unless some option 
like
    > "--force" is added?  Without "--force", an error message could be
    > printed like this:
    > "Using names with uppercase letters A-Z is not recommended, because
    > many broken filesystems (like FAT and NTFS) map upper and lowercase 
letters
    > together; the resulting confusion can risk data corruption.
    > Use the lowercase letters a-z instead of A-Z, to avoid these problems.
    > If you are sure you want to use the uppercase letters A-Z, use the 
--force option
    > to overrid this."

I'm not completely opposed to this idea but I'd be more not completely
opposed if it had the form of a per-user option that had to be on to
enable this behavior and/or a --name-lint rather than --force option.

In some applications (e.g., imagine a wiki) arch will be being driven
by higher-level code which will not want arch to be weakly censoring its
name choices.  Needing a --force option in such cases is pretty icky
-- just having a per-user option to enable --force to be required will
already be enough to make the system as touchy and error-prone as we'd
like :-)

If one wants to think about implementing such checks for
some interactive uses, another thing to keep in mind is that case
issues are unlikely to be the last we'll encounter.    What happens if
we allow category names to include non-ASCII characters, for example?
The portability issues of those are complex and there may be a need
for _other_ kinds of checks, too.


    > Since it only affects creating NEW categories/branches (and
    > archive names?), it won't affect using any current ones.  And if
    > you know that won't be a problem, you can override.

    > So, it's a convention strongly encouraged by the tool, but
    > easily overridden if you don't agree.

I'm not too enthusiastic _at_this_time_ about strongly encouraging a
particular convention in the core functionality.

Some experimentation and careful reporting about the current and
probable future of the state of portability in filenames, especially
with consideration of extended character set issues (character set
choice, encoding system choice, and canonicalization form issues)
would provide enough context to think about what kinds of conventions
to strongly encourage.


    > BTW, I limited this to A-Z.  Perhaps it shouldn't permit
    > "uppercase letters" in general, but I bet the various case-folding
    > filesystems aren't that smart.  I'll bet they do A-Z => a-z and
    > nothing more, because of the complexities of international languages.

Yeah, that kind of question.  I don't want to just take guesses in
this area.  Making changes to what kinds of names and filenames are
permitted is, because of long-lived backwards-compatability
requirements, kind of a one-way street.   This is why, for example,
`inventory' remains quite conservative for the moment.

In general, I think we have to accept that, although arch supports
distributed development, just as in every other aspect of distributed
development, the user community of a given tool is going to partition
into subsets which adopt conventions that result in data not flowing
smoothly between the subsets.  I think the right answer for the tool
here is to permit this to happen rather than trying to fight it by
outlawing the conventions some subcommunities might otherwise want to
adopt -- at least until we have a _really_ solid idea of what the
"universal standard" should be.

Again, I'll point to something like tar.  It's a standard implemented
nearly everywhere for shipping files around and, as such, functions
pretty well.  But it lacks any arbitrary restrictions that would
prevent me from creating a tar file that you can't read correctly on
your ci filesystem.  [flames about the arbitrary limitations tar
_does_ have are taken as read :-)]

-t