On Wed, Mar 19, 2003 at 11:01:37PM +0000, Julian Foad wrote:
> Branko ??ibej wrote:
> >Greg Stein wrote:
> >>* is there a future scenario where revisions do not need to be
> >>time-ordered,
> >
> >As far as I know, there is exactly one reason why our commits must be
> >time-ordered: So that get_revision_by_date can do a binary search on
> >revision numbers.
>
> I don't have enough experience with this. Could someone else verify
> that that is the only reason?
Yup, it's true. We use a binary search to locate a revision for a given
date. That requires that the revs/dates are ordered.
> Is get_revision_by_date not used to find the beginning and end of a
> range of revisions (rX -> rY), with the assumption that this will be
> equal to the set of changes made between dates X and Y?
Hmm. Interesting point. I'm not sure that I truly follow the question, but
the point seems to be:
1) map date X to rev rX
2) map date Y to rev rY
3) the range [rX,ry] does not necessary correspond to
revs R where X < date(R) < Y
In other words, when the SVN client deals with a "range bounded by dates",
it is assuming that can directly translate to a revision range. But the
reality is that a date range can refer to an arbitrary assortment of
revisions in the repository.
For example:
$ svn log -r {march 1:march 3}
the revisions in that range could be rev 1, 10, and 307.
Sigh.
> >If we added an extra date->revision index, this
> >ordering wouldn't be necessary any more and we wouldn't need
> >svn:original-date.
>
> So svn:date would no longer mean "date of this revision" in the context
> of an SVN (as opposed to CVS) revision. I cannot see clearly whether
> this change to the semantics of svn:date is safe.
No no... nobody has suggested changing the meaning of svn:date. That
absolutely means the time when the revision was committed.
The question that I raised was that we might want to record the logical date
of a change, rather than when it was placed into the SVN repository. But
since svn:date must be ordered, that implies a separate property or the
alteration of the svn:date ordering requirement.
> For instance, assume a combination of regular SVN commits and back-dated
> CVS2SVN commits resulted in this history:
>
> r2 10 Jan Added foo.c
> r3 8 Jan Added bar.c
>
> Then I request:
>
> svn co --revision {"9 Jan"}
>
> Which file(s) will it check out? Which should it check out? This
> obviously isn't intended as a multiple-choice question, but a policy
> decision.
It should check out r3. That is the revision that was extent on Jan 9.
Of course, the interesting problem is when you also look at r1 in your
scenario:
r1 6 Jan Added bloo.c
r2 10 Jan Added foo.c
r3 8 Jan Added bar.c
When the repository only has r1 or r1..r2 in it, then you'll get a different
set of data for a "Jan 9 checkout" compared to after r3 has been committed.
> I have no reason to uphold the requirement for svn:date to increase
> monotonically, except that I feel there may BE a good reason for it already.
Very good points. Thank you.
I'm thinking that we shouldn't mess with a DATE->REVNUM index, and continue
to stick with the requirement that revisions must be committed in a
monotonically-increasing fashion.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 20 09:30:47 2003