On 1/13/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> We don't actually _rely_ on svn:date being a monotonically
> increasing sequence anywhere, do we?
'svn subcommand -r{DATE}' depends on that assumption. It's a
long-standing bug, see issue #752:
http://subversion.tigris.org/issues/show_bug.cgi?id=752
Typically, this situation only happens when you load successive
dumpfiles into a repository (i.e. merging histories together). The
ASF has one giant repository, for example, which holds all their
former CVS projects. They've just learned to live with the fact that
-r{DATE} is unusable. But by committing this fix to FSFS, we've at
least lowered the probability that the "unordering" can happen in
normal, everyday use.
It's really a design flaw. The problem that the server tries to
translate -r{DATE} into a single revision by doing a binary search.
To quote Greg Stein:
"[...]if you have DATE1:DATE2, that becomes REV1:REV2. That is way
wrong, as that revision "range" might not really be all of the
revisions between the dates, or REV2 could even be earlier than REV1,
or some of the selected revisions might not be in the date range.
DATE1:DATE2 should really map to {R1, R3, R14, R7, ...}. IOW, some
ordered list of arbitrary revisions. The client is NOT set up for that
at all, not to mention all the server and transport bits necessary to
provide it."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 13 17:16:31 2006