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

[Christian Thäter]

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

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.

How about adding a encoding string to the =tagging-method. That allow early 
recovery and better linting options.
Note: maybe there should also be a list of filesystem hints. since some 
filesystems are pretty restrictive on names (imagine iso9660). 

> I realize that the bulk of this is a global change that really wants
> merging all at once but it sure would be swell to break it up into
> independently useful parts and independently testable parts and merge
> in increments, a few days apart, both to simplify review and to get 
> test-by-using at better granularity.

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)


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


        Christian