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

Re: RFC: Revision indexes for 1.1

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-04-20 00:53:59 CEST

Greg Hudson wrote:

>I'm not sure this proposal solves any common problems.
>On Mon, 2004-04-19 at 02:39, Branko Čibej wrote:
>>This indexing would happen automatically (probably implemented at the
>>repos layer, rather than the filesystem layer),
>I don't like the implication that the FS doesn't maintain its own
>integrity here.
I agree. This is in keeping with current practice, e.g.,
svn_repos_dated_revision is a repos-layer function, or hooks not being
triggered by FS code. Going towards 2.0, I'd definitely want the FS
schema to change in a way that would better support indexing by revprop.

Perhaps we should implement the indexing at the FS level, at that.

>> * Multiplicity: Controls whether, for the same propname, more than
>> one (propname, value) pair can map to a single revision.
>How could you get multiplicity? A propname can't have more than one
>value in a given revision.
This is about how that value is _interpreted_ for indexing purposes. The
svn:name (or svn:label) property's value would contain several lines, e.g.

    $ svn pg --revprop -r 9789 svn:name

This would produce three keys in the revprop index that point to r9789"
(svn:name 1.0.3_RC1), (svn:name Fix_#1435) and (svn:name

This allows us to set several labels on the same revision.

>>The function svn_repos_dated_revision changes: first, it calls
>>svn_repos_revision_search("svn:date", timestamp). If this returns a
>>non-empty list, it returns the oldest revision from this list. Otherwise
>>it performs the current binary search. (The binary-search implementation
>>must stay for backward compatibility. It can be removed in 2.0.)
>>svn_repos_committed_info and svn_repos_history get similar changes.
>I don't think you've made any progress on the date-search problem. Your
>proposal only works when I ask for a date which *exactly* matches the
>one on the revision. But -r {date} is supposed to evaluate to the
>revision number which whose date is most recent as of the specified
Yeah, I totally borked this one. My bad, lack of sleep. Rather I
should've said that svn_repos_dated_revision _uses_ the dates in the
revision index to find the matching revision. Actually we'd have to
deprecate this function anyway, and add a new one that accepts a start
and end date, and returns a list of revision numbers that fall between
these dates.

>If revisions have their dates out of order, then -r {date}:{date} will
>evaluate to a revision range which does not reflect the date range. So
>I think we're better off trying to enforce in-date-order revisions than
>we are trying to make our system work with out-of-date-order revisions.
No, I'm totally against enforcing the date order, for the reasons I
stated. Instead we should just fix the API.

>>4.2 svn label [-r revnum/range/list] label-name
>>4.3 svn labeldel [-r revnum/range/list] label-name
>I have an interest in keeping our command set small; I think having a
>large command set makes our learning curve higher. So I'd prefer to see
>the usual rev-prop commands used to set and remove revision labels if we
>must have them at all.
I would agree, except that adding these two commands makes it much, much
easier to manipulate a) multiple labels on a single revision and b) a
single label on multiple revisions (you can't actually do the second
atomically with the rev-prop commands at all).

-- 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 00:53:49 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.