Julian Foad wrote:
> 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?
http://svn.haxx.se/dev/archive-2004-04/0973.shtml
>> 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?
Well, SVK already seems to have problems because of this. cvs2svn is an
order of magnitude more complicated than it would have to be if revision
ordering and date ordering weren't necessarily the same. Repository
synchronisation (svnsync) probably has hidden issues. Etc.
> 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.
svn:date should be the date when a changeset was created, not
necessarily in "this" repository.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 17 10:37:03 2006