[Bug-gnu-arch] [bug #6059] support for per-directory categorization regexps

[nobody]

=================== BUG #6059: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6059&group_id=4899

Changes by: Robin Farine <address@hidden>
Date: Sat 11/08/03 at 23:21 (Europe/Zurich)

------------------ Additional Follow-up Comments ----------------------------
OK, I took a look at your augmented test case, that is not

how I intended the local stuff to work. If you want things

to be locally categorized, you need to define a regexp that

is actually including them.



So, if you want to add 'core' to a directory's source

category then redefine the source category to include core.



Doing it that way ensures that any exception handled by

locally defined regexps is immune to changes in the global

regexps.



=================== BUG #6059: FULL BUG SNAPSHOT ===================


Submitted by: rfarine                 Project: GNU arch -- a revision control 
system
Submitted on: Mon 10/20/03 at 01:21
Category:  tla                        Severity:  5 - Major                  
Bug Group:  small feature idea        Resolution:  None                     
Status:  Open                         Release:  
address@hidden/tla--devo--1.1--patch-188
Fixed Release:                        Merge Request?:  yes -- merge from my 
archive
Your Archive Name:  address@hidden Archive Location:                
Assigned to:  None                    

Summary:  support for per-directory categorization regexps

Original Submission:  address@hidden

  tla

    tla--rnf

      tla--rnf--1.1



        patch-8    (simple changeset)

          support for per-directory categorization regexps





A file named '.arch-inventory' can locally override the

common categorization regexps for entries in the directory

which contains it by redefining a subset or all of the

regexps defined in '=tagging-method' (exclude, junk,

backup, unrecognized, source).



While processing a directory with such a file, the

inventory process first tries all of the locally redefined

regexps and, if no one matches, it falls back to the common

regexps.



Follow-up Comments
*******************

-------------------------------------------------------
Date: Sat 11/08/03 at 23:21         By: rfarine
OK, I took a look at your augmented test case, that is not

how I intended the local stuff to work. If you want things

to be locally categorized, you need to define a regexp that

is actually including them.



So, if you want to add 'core' to a directory's source

category then redefine the source category to include core.



Doing it that way ensures that any exception handled by

locally defined regexps is immune to changes in the global

regexps.

-------------------------------------------------------
Date: Sat 11/08/03 at 21:36         By: robertc
Actions speak louder than words: I've extended your test cases in 
address@hidden/tla--integration--1.1--patch-5 (your tests will never fail I 
realise - you need to rework your test script - see the bottom test I've added 
as an example) to test for regexp relaxation. In the test I setup an 
environment where 'core' should be considered source - and it is still 
considered unrecognized. 



And yes, I do mean that all local regexps should be tested before all global 
regexps - but it's not how I read the source, and it's not how my test case 
suggests it operates.

-------------------------------------------------------
Date: Sat 11/08/03 at 13:52         By: rfarine
Rob,



Not sure I understand your suggestion correctly. If you

mean that all of the locally defined regexps should be

handled first and then try the global regexps if no match

was found, then that is what

arch_inventory_traversal_internal currently does.



I hesitated to factor the matching code out of

arch_inventory_traversal_internal but I thought that

the goto logic already in place perfectly suited my

needs.



-------------------------------------------------------
Date: Sat 11/08/03 at 13:52         By: rfarine
Rob,



Not sure I understand your suggestion correctly. If you

mean that all of the locally defined regexps should be

handled first and then try the global regexps if no match

was found, then that is what

arch_inventory_traversal_internal currently does.



I hesitated to factor the matching code out of

arch_inventory_traversal_internal but I thought that

the goto logic already in place perfectly suited my

needs.



-------------------------------------------------------
Date: Sat 11/08/03 at 11:59         By: robertc
Merged into address@hidden/tla--integration--1.1--patch-2 and -3. On a code 
style note, it appears to me that the evaluation of the per dir and global 
regexs may be 'wrong'.



i.e. currently you evaluate:

dir, global X, for X in excludes, junk, backup etc etc.



This means that a per dir regex that is less strict for excludes cannot 
override a more strict global excludes (and likewise for backup, source etc).



So, I suggest that you change the order:

dir X for all X, followed by global X, for all X.



This could be neatly implemented via a subroutine that takes a pointer to the 
regexps struct, extracted appropriately from arch_inventory_traversal_internal.



I've merged your code anyway, to give folk 'out there' a starting point for 
experimentation.



-------------------------------------------------------
Date: Sun 11/02/03 at 02:48         By: rfarine
Merge upstream changes, provide inventory ids for

".arch-inventory" files and add a test case.



address@hidden

http://213.200.230.54/{pubarch.v2}/address@hidden/2003

  tla

    tla--rnf

      tla--rnf--1.1



        patch-8    (simple changeset)

          support for per-directory categorization regexps



        patch-9    (simple changeset)

          merge from address@hidden



        patch-10    (simple changeset)

          name inventory ids for ".arch-inventory" files



        patch-11    (simple changeset)

          test case for per-directory regexps






CC List
*******

CC Address                          | Comment
------------------------------------+-----------------------------
address@hidden             | 



No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6059&group_id=4899

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/