[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SVN snapshot versioning



On Tue, 23 Jan 2007 12:31:39 +0100
Stefano Zacchiroli <zack@debian.org> 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/

Attachment: pgprXJiwLX9be.pgp
Description: PGP signature


Reply to: