[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Revision indexes for 1.1

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-20 01:45:36 CEST

Chris Foote wrote:

>I have one small question though.
>
>----- Original Message -----
>From: "Branko ÄOibej" <brane@xbc.nu>
>
>
>>3.3 Indexing configuration
>>
>>The repository grows a new configuration file, conf/revpropindex. The
>>format of the file is as follows:
>>
>> [propname]
>> unique = [TRUE/false]
>> multiple = [FALSE/true]
>>
>>
>>
>Wouldn't it be better to make this the start of the conf/repos.conf file for
>all repositry
>configuration?
> That way only *one* config file would need be read.
>
>
Possibly. That would only require a syntax change. (Although the fact
that we allow colons in property names does complicate matters somewhat.)

>>Revprops that do not appear in the config file are not indexed. The
>>default contents of this file are:
>>
>> [svn:date]
>> unique = false
>> multiple = false
>> [svn:name]
>> unique = false
>> multiple = true
>>
>>The svn:date and svn:name indexing cannot be turned off, neither can the
>>indexing parameters change (in effect, we may as well not actually
>>enable these in the revpropindex config file).
>>
>>
>>
>What happens when someone adds a new revprop to the config file?
>If you already have a repo with some props indexed and then decide to add
>another/remove one, would this require a dump/load cycle?
>
>
Only if you want to add existing instances of that property to the
index. Of course we could also add a "svnadmin reindex" command, or
something similar, for maintaining the revprop index. That might be a
good idea in any case.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 20 01:45:27 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.