Greg,
I appreciate your thorough response.
I will probably take a look at the implementation. There are already a lot
of repositories out there which do not have the expected behavior for date
... just "svnadmin load <into sub-branch of existing repository>" and merge
two repositories.
-----Original Message-----
From: Greg Hudson [mailto:ghudson_at_MIT.EDU]
Sent: Monday, September 29, 2008 5:32 PM
To: Paul Charlton
Cc: 'Subversion Developers'
Subject: RE: svn revision r0 question
On Mon, 2008-09-29 at 14:24 -0700, Paul Charlton wrote:
> "{2007-01-02}" is inherently a set, with zero or more members.
You are describing something out of your own mental model of some
otherworldly ideal revision control system.
In Subversion, {date} is resolved to a point in time (not a day or
anything like that), which is in turn resolved to the first revision
whose timestamp is no later than that point in time. (I may have the
edge case handling wrong there; I'm not sure what happens if one or more
revisions exactly match the specified timestamp.)
That may not be the best architecture, but it is what we have. If
revisions are not linearly date-ordered, the meaning of {date} *in
Subversion* is not defined. Handling that sort of repository is not a
simple matter of replacing the binary-search implementation of {date}
resolution; it is a matter of redefining the semantics of {date} in
every command which can operate on a revision number and reworking every
API which implements those commands. In some cases, syntaxes which are
valid and well-defined now would have very different meanings or no
meaning, like "svn diff -r {date}:HEAD path".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-30 07:50:59 CEST