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

[David A. Wheeler]

I said:
> Here's an idea: why not reject making NEW categories, branches
> (and maybe archives?) with the uppercase letters A-Z, unless some option....

Tom Lord replied:
>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.

Users need to be able to override, we agree on that.
But I don't think the default (limit or no limit) should be
JUST dependent on the user.  Here's why:
Any one developer is likely to cooperate with
many projects, and those different projects are likely to represent
different communities.  Some communities may have no problems with
mixed-case, some will.  Indeed, a community may have no problem now and
later on acquire a problem with mixed-case.  A developer may not know
offhand what the community norms are, because it's based on a transitive
closure they may not be familiar with yet.  And it could always change:
arch never runs on win32, except now it does :-).

The default shouldn't be just per-user, it's really per-community + per-user.
As an approximation of "per community", the default "name lint value"
could be set per-archive and still allow a user override.
But I still think you're better off with a conservative linting as the default
(warn about names you KNOW doesn't work in some cases).

>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.

If any tool wants to use an arbitrary name, and they know
that they won't have problems, they can add --force or whatever.
It's so weak a limit that it's not really censoring at all; it's just
requiring users to specifically allow a somewhat dangerous operation.
If these putative wiki developers really want mIxEdUpArChBrAnChEs
they can easily add --force.  What concerns me more is the developers
who don't know about the problem, and accidentally cause
themselves data corruption down the road.

And the real issue, in my mind, is avoiding data corruption.
Corruption is bad, bad, bad, we'll all agree :-).
If there's a better solution, great.

> 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.

I agree, and we can't expect users to know all the checks needed.
So if the TOOL is the one that knows and checks, that's one less thing
the user has to worry about.

>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.

That's rather broad.  Can we narrow that?  I think the real issue is,
"what might get mapped into overlapping mappings and cause data corruption
on various filesystems", yes?  It'd be a very good idea to collect
this data.  No doubt.

But we already know of a case where things can get
screwed up: mixed A-Z with a-z.  We could start by restricting THAT,
and then add other restrictions on creation when other problems are found.
This isn't really a backwards-compatibility problem, since I'm only
suggesting a limit on creation, NOT on use once it's created.

And there are two issues: (1) names of archives/categories/branches, and
(2) names of the controlled files. In case (1),
limiting the names of archives/categories/branches is probably much
easier to swallow, because fundamentally they're a construct only
of arch itself.

If you're really balking on the "forbid as default", why not start
with a simple warning message when A-Z are used in categories,
branches, or archive names?  That way it won't even force anything at all,
and users who decide to create them may decide to suddenly un-create them.
(hmm, probably needs to be rm- versions of the make- commands).
I'm sure there's more to do in i18n, but we don't need to solve the
world's problems to avoid this particular problem.

--- David A. Wheeler <address@hidden>