2005/6/27, Andy Cutright <Andy.Cutright@borland.com>:
> if i use the revision number associated with the log i always get the
> version i'm expecting. if i use the date associated with the same log
> message, i get either no version if i'm trying to checkout the first
> controlled version of an element in the repository, or i get the version
> just before the the one i'd expect for later commits.
Well, this way could indeed be seen as the "correct" way although it
might not look very logical in the first place.
You are just falling into the same pit as many others (me too) in the
beginning. It is the revision/changeset duality. In subversion, each
particular revision number X actually means two different things,
depending on the context:
a.) the contents of the repository as it is in revision X
b.) the changeset that converted the repository from revision X-1 to
revision X.
The timestamp you see in the revision log is exactly the time at which
the repository was converted from one revision to the next. So at the
exact moment of that conversion, the repository was at the old state,
where at the next time increment the repository is at the next
position.
So this log entry means:
------------------------------------------------------------------------
r5 | acutright | 2005-06-17 11:59:45 -0700 (Fri, 17 Jun 2005) | 1 line
at exactly 11:59:45, when the repository was at r4, acutright did a
checkin and created r5.
I personally would find it more logical to define the revision date as
the birth of the new revision instead the dead of the old one. It
would make the whole thing more consistent. But this is the way
subversion was done. Maybe a developer can tell if that was a design
decision or if they just overlooked this?
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 27 20:18:38 2005