Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#18224 closed Bug (fixed)

`django.utils.version.get_svn_revision` isn't appropriate anymore

Reported by: Aymeric Augustin Owned by: Aymeric Augustin
Component: Core (Other) Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

We're no longer using SVN.

Callers of this function, like django.get_version, need to be updated.

Attachments (1)

18224.patch (4.0 KB ) - added by Aymeric Augustin 12 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by Aymeric Augustin, 12 years ago

Owner: changed from nobody to Aymeric Augustin

by Aymeric Augustin, 12 years ago

Attachment: 18224.patch added

comment:2 by Aymeric Augustin, 12 years ago

Here's an in-place replacement for the existing functionality.

We can't use the SHA1 of the changeset because the identifier must be numeric.

We can use either a human readable timestamp (14 digits) or a Unix timestamp (10 digits). I implemented the first one, even though it's longer, because it will be easier to locate the corresponding changeset in GitHub (or any other git UI).

comment:3 by Aymeric Augustin, 12 years ago

#18228 was a duplicate.

comment:4 by Daniel Swarbrick, 12 years ago

Perhaps it might be a good idea to append the abbreviated commit hash to the date in the 'git show' command, eg

git show --pretty=format:%ct-%H --quiet HEAD

which yields an output like '1335619144-10cade8fac143984fc8416f3179c955e9f0c7f7b'. Github appears to use 10-digit abbreviated hashes, as opposed to Git's 7-digit ones. If the commit hash was shown in the version number, using the same format/length as Github, this would make it even easier to locate the commit. Also, if the commit hash is explicitly included in the version stamp, perhaps the timestamp could just be a Unix timestamp afterall.

comment:5 by Aymeric Augustin, 12 years ago

Unfortunately we can't include the hash because the version number would no longer comply with PEP 386.

comment:6 by Daniel Swarbrick, 12 years ago

In that case the "devN" suffix becomes rather useless, or at the very least, quite inconvenient. Is it worth adding a separate function (not used to build the version stamp) which actually does return the Git commit hash?

comment:7 by Aymeric Augustin, 12 years ago

If we don't include this suffix, all post-1.4 versions will be labeled 1.5, which is rather confusing. The suffix makes it clear that it's a development version.

Where would Django use a Python function returning the git commit hash?

comment:8 by Aymeric Augustin, 12 years ago

Resolution: fixed
Status: newclosed

comment:9 by Daniel Swarbrick, 12 years ago

I didn't suggest not including the suffix. I suggested included a function to retrieve the git commit hash, for debugging purposes, to make it easy to locate the particular code revision now that Django is hosted on github.

Note: See TracTickets for help on using tickets.
Back to Top