Re: [Lxr-dev] Re: /bin/true as a zombie

[Malcolm B. <ma...@br...>]

Peder O. Klingenberg wrote:

>Jason Dorje Short <js...@de...> writes:
>
>>No doubt I'm missing something, but I don't understand why my change was
>>conceptually wrong.  I took each version to be indexed, and traversed
>>the tree for that version.  
>>
>But you can't find the versions to be indexed by asking for the
>versions of the root of the tree.  In a CVS tree, each file can have a
>differing number of versions, have completely different tags, etc.
>
Absolutely true.  Simply because files are in the same CVS archive 
doesn't mean that they are even logically in the same project, let alone 
the same release!  However, with the plain file storage, the versions 
are physically separate, and in other SCM systems they could either be 
physically separate (a different pathname) or simply different versions.

>>The current/former behavior is to traverse the tree, and for each
>>file index it for all possible versions.  
>>
>
>Yes, that was the point.  Unless you specify a version, you get all
>the versions a file has to offer.
>
>That was at least the concept I had of --allversions, and your patch
>didn't fit that concept.  Hence conceptually wrong.  It may of course
>well be that my concepts are different from yours, in which case it's
>a matter of opinion which version (pun intended) to hold as the
>correct one.
>
I think this is the key difference between people using CVS.pm and those 
using Plain.pm.  You can't traverse a filetree in Plain.pm and ask what 
versions the file has, since the different versions have different 
locations.  On the other hand, with CVS each file can have multiple 
versions.

>>BTW, the new genxref doesn't work for me again.  It runs through all
>>versions just as if everything had already been indexed, even
>>immediately after I drop and re-create the database.
>>
Same for me here - file->allversions() doesn't seem to work for 
Plain.pm.  I think some test code for the lxr is badly needed :-)

>Maybe this is because Plain.pm and CVS.pm disagree on how to compute
>allreleases?  I've never looked at Plain.pm, so I don't know.
>
That would appear to be the problem, looking at Plain.pm

>It seems to me that this is an area that needs more customization,
>because we obviously disagree, and I suspect that we both have equally
>valid views.  And as it so happens, we have a configuration variable
>by the name of 'range'.  Would you be happy if --allversions just used
>the range in lxr.conf?
>
That seems to me to be the best solution - then the user gets to pick 
what versions are indexed, and it's easy to make range be equivalent to 
the current "allversions" for the CVS backend.

>I've already patched Config.pm to accept closures for this variable in
>order to get the cgi scripts to display versions based on the versions
>of each file, so I think I could make this work for me.
>
>It would still need to use the original control flow in order to allow
>the flexibility I need, but specifying a constant range list (or file)
>in lxr.conf should give the same semantics as precomputing the
>versions to index, should it not?
>
It would, yes.

Malcolm