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
1.0.3_RC1
Fix_#1435
1.0.4_merge_candidate
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
1.0.4_merge_candidate).
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
>date.
>
>
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