Re: [Gnu-arch-users] Increasing the filename space (Or: begging for trouble?)

[Tom Lord]

    > From: Christian =?ISO-8859-1?Q?Th=E4ter?= <address@hidden>

    >> I'd appreciate it if it were parameterized by a regexp that can be set
    >> in =tagging-method.  The default should not change.  The main idea
    >> being that tree-lint really is useful as a lint-like tool for
    >> filenames.  The secondary idea being that that is an upwards
    >> compatible way to make the change.

    > I rather see problems in the way the underlying access
    > method/filesystems handle international characters. That cannot
    > be covered in =tagging-method and tree-linting is clueless
    > there.

Until arch starts using UTF-8 for filenames internally, the hard-coded
7-bit invalid_characters test must remain.

The hard-coded "spaces and glob characters" test can go away, but
should remain as the default and be supplemented by a =tagging-method
override.

Eventually, all hard-coded restrictions will go away (while the
default remains in its current state).



    > Probably we need to abstain from the idea that everyone can
    > checkout every other archive when he doesn't use an utf-8 aware
    > filesystem.

That's false.... but our messages are probably crossing on the list.
I've explained how to do it.


    > How about adding a encoding string to the =tagging-method. 

Please catch up with my recent messages in this thread.


    [merge plan]
    > parts/patches will be:
    >   1) the hackerlab infrastructure basics, that is string     
transformation, not i/o there.
    >   2) escaping handler/interface for tla, i/o defined here
    >   3) global tla modification for handling escaped characters
    >   4) a bunch of single patches which make additional things work
    >      escaped logs/inventory printout and so on
    >   5) a 'tla unescape' and 'tla escape' command as tool for scripts        
6) hackerlab escaping performance improvements
    >            (perfect hashing, AVL-Tree lookup etc)

Please elaborate on what you mean by 4 and 6, and why 5 is needed.

Also: have you been using and do your patches include updates to both
the tests run by `make test' and the `changeset-tests'?   The latter
is absolutely critical.

Documentation updates for the new =tagging-method option are also
important.


    >> (All of those can hopefully go in a single preX release -- I'm just
    >> talking about staggering them into the head revision between preX
    >> releases.)

    > You expressed that you already have enough code to review. 

I don't think so.

    > So my suggestion is that I will keep a tla-branch for some short
    > time (a week or so) for testing in the wild by interested
    > users. 

I discourage that.  In particular: it does very little to advance my
confidence for merging;  similar attempts in the past have left users
with corrupt archives;  you seem to be trying to be sneaky.

    > You can take a look on the code at first or wait until it
    > settled and matured a bit, I will then send you a merge request
    > after that.

-t