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

Re: Date ordering of revisions [was: fsfs bug in commit timestamps?]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-01-17 00:51:01 CET

Tony Overfield wrote:
> I should have been more persistent, but I previously reported
> this to the users list.
> See "Unordered commit dates from ordinary commits",
> http://svn.haxx.se/users/archive-2005-09/0599.shtml

 From that message:
> While committing a long-running commit, if a shorter commit is started
> and completed before the long-running commit has finished, it creates
> unordered svn:date properties.
> I am using Windows XP with:
> svn, version 1.2.3 (r15833)
> compiled Aug 19 2005, 23:10:39

Thanks for reporting it here now. It sounds like that's the bug found and
fixed recently (in trunk r18078) that's specific to FSFS; Berkeley DB
repositories don't have that bug.

The fix does not appear to have been back-ported to the 1.3.x or 1.2.x
releases. I suggest we propose it for both. Yes, other committers?

> The book states that the svn:date property is set when the transaction
> is created, but wouldn't it be better to use the time at which the final
> revision number is obtained?

Ah, the book is misleading. It's strictly correct in what it says, as the
"svn:date" property is initially added at creation time (useful for an
administrator looking at the transaction before it is committed or if it fails
to be committed), but the book fails to say that "svn:date" is updated when the
transaction is committed.

Would you care to make a patch to correct the book XML file (en/book/ch05.xml,
section "svn.reposadmin.basics.revprops")?

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 17 01:06:50 2006

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.