Branko Čibej wrote:
> Alan Barrett wrote:
>
>> [...] Under your proposed new regime, copying
>> svn:date properties will not be allowed if that would cause the dates
>> to become out of order, and that will happen very often when people use
>> svk mirrors in the usual way. [...]
>
> This is yet another reason to resurrect my idea that we should introduce
> a secondary index for dates, and enhance the date search routines.
It sounds like you're suggesting a piece of implementation beneath the "find
the last revision before a given date" interface, to make it work even if the
dates are not in order. That's fine as far as it goes - "svn log
-r{2000-01-01}" would indeed then show the last revision having an "svn:date"
before 2000 - but what would it mean, what would be the benefit, in a
repository without strict ordering? That's closely related to my last
paragraph below.
The problem is that the "last revision before a given date" interface itself is
not very useful in that situation, as far as I can see. Do you have an idea
for a new API and high-level functionality that would make use of your indexed
date look-up function?
> The requirement that svn:date ordering == revision ordering is too restrictive.
Too restrictive for what? (Genuine question, for anyone who feels like
tackling it.) What exactly is it that people want to do with non-sequential
dates, or rather (perhaps) dates that are only sequential within some
particular subsets of the node-path space of the repository?
Alternatively, I could ask this way: If "svn:date" is not necessarily going to
be the date of commit to this repository, then what is it going to mean? There
doesn't seem to be any point in having a dedicated short-cut ("-r{DATE}") for
operating on it unless we can specify what it means.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 17 01:11:30 2006