On Tue, 23 Jan 2007 12:31:39 +0100 Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 23, 2007 at 09:35:38AM +0000, Neil Williams wrote: > > As commented elsewhere, normal release numbers do not have any date > > component and you've still got the problem that multiple svn commits > > are frequently made on the same day. The date, in this context, is just > > misleading and would need to be a full UTC timestamp to have any real > > meaning. The revision number is far more precise and just like a normal > > My feeling is you're kinda nitpicking here, but let me play your game :) Not really, I'm just feeding back on a real issue I faced with a previous project. > Unless you, as a Debian packager, are packaging a CVS/SVN/... snapshot > whose date is "today" this is a bogus problem. Not true. With an active project, there could be 100 commits on any one day. These happen at various times, from various timezones. You check out a revision for a specific point in time, it isn't obvious whether that includes revisions made in a different timezone. Even if you specify 00:00:00 to take the last commit of the day, it still isn't obvious whether that includes a commit from someone +0800 or -0700. The user needs to know your timezone or the timezone of the server which is even more obscure (and can change). Individual commits are not one-liners, many commits touch dozens of files. I've made commits that touched 30% of a 95Mb codebase in a single revision. I've made commits that changed 1 byte. I've made dozens of commits in one day, I've gone hundreds of days without any commits. I've been in projects where half a dozen developers in four different timezones all commit (more than once) to the same branch on the same 'day'. It is no surprise that active projects have svn revision numbers in six digits whilst still at release 2.0. > Indeed if the date > timestamp is at least yesterday [1] the amount of commit occurred until > that day can no longer change. When looking backwards in the commit list, you still have the timezone problem - just because there can be no more changes on that date, does not change the fact that changes could easily have been made either side of midnight in your timezone that would be deemed the same day for someone in a different timezone. You end up having to specify a full UTC timestamp. > Using both CVS and SVN you can > checkout/update your working copy up to that date without any possible > confusion. Not true. You cannot reliably ensure that a commit at 11:50:00 -0500 is actually part of your daily snapshot without specifying your timezone in the snapshot date, i.e. creating a full UTC timestamp in the version string. Many free software developers are most active in the evening (in their timezone) so this problem occurs frequently. The svn 'r' system is specifically designed to cope with this inadequacy of CVS - it is, IMHO, crazy to dump it for imprecise and inaccurate 'date' strings. Using a full UTC timestamp is even worse - far too messy. Looking up an 'r' number is as trivial as putting "svn r12314 project" into google. I really don't see what could possibly be easier. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpKPNxduxokV.pgp
Description: PGP signature
