Re: [Gnu-arch-users] [PATCH] my-project-id

[Tom Lord]

    > From: Russell <address@hidden>


    > How should these be stored?  All in one file with one regexp/id pair per
    > line?

    >   $ cat ~/.arch-params/=ids
    >   address@hidden/ Tom Lord <address@hidden>
    >   address@hidden/emacs.*  Tom Lord (emacs hacking) <address@hidden>

I think so except: reverse the order of the fields to avoid syntactic
ambiguity.  

In my proposed revision to your hack, I burbled about prioritizing
matches based on the specificity of regexp sets but that turned out to
be bogus for several reasons.  A single file which lists the patterns
and ids in the order to be tested makes more sense.


    >> Setting an id should work like:

    >>   tla my-project-id SCOPE ID

    >> where SCOPE is any of: [....]

    > It appears that there are a couple of cases here that need some
    > help to distinguish.  The regexp '.*gnu--.*' can match the
    > archive 'address@hidden' or the branch 'gnu--devo'.  Do we
    > require that the archive regexp be distinguished by the presence
    > of '@' or a trailing '/'?

The trailing /.

Please note that the parser for regexp sets has to be carefully
designed.  For example, "/" terminates an archive regexp but not just
any "/".

This is a _category_ regexp set:

        foo.*[/xyz]

but this is an _archive_plus_category_ regexp set:

        foo.*/xyz

And, this is a _category_plus_branch_ regexp set:

        foo--bar

but this is a _category_ regexp set:

         foo[--b]ar

and this:

        foo--*bar

is a _category_plus_branch_ regexp set whose branch regexp,

        *bar

is not Posixly correct.


    > >   ARCHIVE_REGEXP/CATEGORY_REGEXP--BRANCH_REGEXP--VERSION_REGEXP

    > So when tla is searching for the most specific match, 

Forget that part (specificity ordering).   It was just plain wrong.
Search in the order of the lines in the ~/.arch-params file, using the
first match.   `my-project-id' should append to that list.   Users can
edit it by hand to change the order.

Sorry for the red herring.


    > it should step
    > through the regexps, and for each one that matches decide if it is more
    > specific than the last.  You mentioned ordering in another message,
    > which is the question that pops up here.  There does need to be some way
    > of ordering these things.

Just the order of lines in the file.


    > Mostly.  You also mentioned regexp sets in rbrowse elsewhere.  I tried
    > that out and got these results: [....]
    > Is that what you would have expected?  

Since I'm busy unpacking I didn't study that example but, if there are
surprises there, I'm not surprised.

That's kind of the point of "overengineering" the regexp-set mechanism
at this stage.  Now that we realize it's going to be a commonly needed
thing, let's do the hard detail-oriented work of getting it Right.


    > From your comments above ("a
    > "regexp set" is 1..4 regexps delimited similarly to project names") I
    > would have expected that that 'makediary.*k' should not match
    > makediary--trunk, because it seemed that each regexp in the set should
    > be "confined" to one component of the project name.  

Ok, I peaked at that part and, yes, if that's what rbrowse is doing I
think it's not quite right.

    > If I'm correct
    > here, and this is to be factored out of rbrowse so that both rbrowse and
    > my-project-id can use it, we'll be changing the operation of rbrowse.

I think that's ok.   Jblack, ok?

-t