[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: possible bug

From: Andy Cutright <Andy.Cutright_at_borland.com>
Date: 2005-06-27 21:24:58 CEST

if we regard the timestamp as the point at which the repository was in
the old state, what's the point of the timestamp? it can't be used to
retrieve the 'new' revision with any precision. the revision number is a
unique index into the repository, retrieving exactly the version
identified by the revision number, but the timestamp is not.


> -----Original Message-----
> From: Norbert Unterberg [mailto:nunterberg@gmail.com]
> Sent: Monday, June 27, 2005 11:18 AM
> To: Andy Cutright
> Cc: dev@subversion.tigris.org
> Subject: Re: possible bug
> 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?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 27 21:26:03 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.