Ben Collins-Sussman wrote:
> 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
The issue's summary line is "rev_hunt is broken when revisions are not
date-ordered". It acknowleges that there are two alternative solutions: either
make the dates ordered or make Subversion clients cope with unordered dates.
> 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.
That's one view. I prefer to think that monotonic ordering of svn:date is a
requirement, and that a repository that violates the requirement is broken.
Would we be prepared to agree and document something like?:
* "svn:date" represents the date at which this revision was committed to this
repository, and thus must increase monotonically.
* If "svn:date" properties are out of order, up until at least Subversion v1.3,
the only thing that breaks is "-r{DATE}", and in v1.x everything that works in
v1.3 will continue to work but new features that rely on date ordering may be
introduced.
* If you want to record the date at which, for example, the files were
originally committed to some previous repository, and the complete set of such
dates would not be ordered in the current repository, then record those dates
in some other property, not "svn:date".
If we agree, we should do something about enforcing this in "svnadmin load" and
"svn propset".
To address the problems that people currently have with out-of-order
repositories, we could write a "correction" utility which modifies the dates so
that they are in order, possibly preserving the old values into a
differently-named property if required. (This utility need only access the
repository through the software API, though it could alternatively filter a
dump file.)
Thoughts?
> 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."
Indeed. And I don't see any reason to try to make that sort of thing work.
If we really want an ability to select a disjoint set of revisions based on
their properties, we should introduce a generic ability to select a set of
revisions based on any of their properties - e.g.:
((svn:date < 2000-01-01) OR (svn:author == julian)) AND (my:flag != "")
That sort of thing (especially filtering on svn:author) has been requested
before, specifically for "svn log" I think. I don't think there's currently
any other command that could sensibly make use of it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 14 02:18:26 2006