gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Russell
Subject: Re: [Gnu-arch-users] [PATCH] my-project-id
Date: Fri, 23 Apr 2004 10:56:00 +0800
User-agent: Mutt/1.5.4i

On Thu, Apr 22, 2004 at 08:32:16AM -0700, Tom Lord wrote:
...
> May I ask you to revise it somewhat?  Perhaps others facing a similar
> need can help since the revision I have in mind is fairly substantial.

Somewhat?  :)

> I would like ids to be recorded in ~/.arch-params, not in
> $(project_tree)/{arch}.

OK.  I can see an advantage in that: they won't get deleted when I get a
new copy of the tree, which is something I have done fairly often, and
that arch local mirrors make easy.

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>


> Setting an id should work like:
> 
>   tla my-project-id SCOPE ID
> 
> where SCOPE is any of:
> 
>   a fully qualified version name regexp set
>   a fully qualified branch name regexp set
>   a fully qualified category name regexp set
>   an archive name regexp set
>   an unqualified version name regexp set
>   an unqualified branch name regexp set
>   an unqualified category name regexp set

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
'/'?

You've made it intuitively obvious in your example 'address@hidden/'
that that is an archive name regexp, but it needs to be obvious to tla
as well.


> For example, to set my id for all transactions with some hypothetical
> gnu archives I would use:
> 
>   tla my-project-id 'address@hidden/'  'Tom Lord <address@hidden>'
> 
> But there's an exception.   I want to use a different id when
> committing to RMS' emacs categories:
> 
>   tla my-project-id 'address@hidden/emacs.*'  'Tom Lord (emacs hacking) 
> <address@hidden>'
> 
> In general, a "regexp set" is 1..4 regexps delimited similarly to
> project names:
> 
>   ARCHIVE_REGEXP/CATEGORY_REGEXP--BRANCH_REGEXP--VERSION_REGEXP

So when tla is searching for the most specific match, 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.


> The function arch_my_id should accept a parameter -- the project name
> for which an id is needed -- rather than being sensitive to the
> current working directory.    It should be permitted for that
> parameter to be 0 (meaning to just use the default id).
> 
> The list of SCOPEs abave is from most to least specific.   The id
> whose scope is the most specific match of the project name passed to
> arch_my_id should be used.
> 
> That leaves the task of filling in correct parameters in all the calls
> to `arch_my_id' but that's the easy part :-)
> 
> Make sense?

Mostly.  You also mentioned regexp sets in rbrowse elsewhere.  I tried
that out and got these results:

  address@hidden:~$ tla rbrowse makediary
  address@hidden
     makediary
        makediary--trunk
           makediary--trunk--0
               base-0 .. patch-7
  
  address@hidden:~$ tla rbrowse 'makediary.*k'
  address@hidden
     makediary
        makediary--trunk
           makediary--trunk--0
               base-0 .. patch-7
  
  address@hidden:~$ 

Is that what you would have expected?  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.  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.




-- 
Russell Steicke

-- Fortune says:
Beware of a dark-haired man with a loud tie.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]