[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-04-19 17:46:15 CEST

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.

> * 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.

> 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

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.

> 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.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 19 17:46:38 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.