Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Adding SVN revision identifier to version

14 views
Skip to first unread message

Deryck Hodge

unread,
Aug 17, 2007, 3:45:01 PM8/17/07
to django-d...@googlegroups.com
Hi, all.

Reading the Django users list, I saw someone mention not knowing what
the "pre" meant in the version string returned by django-admin.py.
This made me think of version numbers more generally, and I wondered
if others saw value in appending an SVN revision identifier on the
version string.

So instead of 0.97-pre the version would be 0.97-pre-SVN-5919. This
might help make it easier to track down what revision people are
running since so many of us run off trunk. This, of course, would
have no impact on official releases.

I worked up a quick patch, which I can add to a ticket, if others see
any value in this.

http://dpaste.com/17141/

Cheers,
deryck

Dave Rowe

unread,
Aug 17, 2007, 3:51:43 PM8/17/07
to django-d...@googlegroups.com

Are these people always pulling from SVN? Otherwise, it'd always show SVN-Unknown, right? Especially if 'svn' isn't in the path.

Deryck Hodge

unread,
Aug 17, 2007, 4:08:49 PM8/17/07
to django-d...@googlegroups.com
On 8/17/07, Dave Rowe <da...@roweware.com> wrote:
>
> Are these people always pulling from SVN? Otherwise, it'd always show SVN-Unknown, right? Especially if 'svn' isn't in the path.
>

My assumption is that, yes, the majority of users on a "pre" release
are running from SVN. Is there any other way to get a pre release of
Django except via SVN? I thought distros were only packaging official
releases.

But yeah, if they have a pre release from somewhere other than SVN it
would say SVN-unknown. I imagined this to be the exception rather
than the norm. I was picturing SVN-unknown more for the use case
where they had the working copy but no svn tools (i.e. they had copied
to a server via FTP/SCP/etc). There is also the Mercurial branch
Jacob mentioned for distributed development, but again, I thought SVN
was common enough that this revision number would still be useful.

I don't mind refactoring this to just return the normal version string
if no revision number is found, rather than adding SVN-unknown.

Cheers,
deryck

James Bennett

unread,
Aug 17, 2007, 4:14:32 PM8/17/07
to django-d...@googlegroups.com
On 8/17/07, Deryck Hodge <der...@samba.org> wrote:
> So instead of 0.97-pre the version would be 0.97-pre-SVN-5919. This
> might help make it easier to track down what revision people are
> running since so many of us run off trunk. This, of course, would
> have no impact on official releases.

What does this accomplish that 'svn info' doesn't?

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Deryck Hodge

unread,
Aug 17, 2007, 4:27:05 PM8/17/07
to django-d...@googlegroups.com
On 8/17/07, James Bennett <ubern...@gmail.com> wrote:
>
> On 8/17/07, Deryck Hodge <der...@samba.org> wrote:
> > So instead of 0.97-pre the version would be 0.97-pre-SVN-5919. This
> > might help make it easier to track down what revision people are
> > running since so many of us run off trunk. This, of course, would
> > have no impact on official releases.
>
> What does this accomplish that 'svn info' doesn't?
>

Well, nothing, really. :-)

I thought the version might be a little more obvious to the average
end user running the internal Django server since that server spits
out the version string on start up. When asked what version of Django
they're running, they might include the SVN revision if Django spits
it out. Plus, it would make `django-admin.py --version` a little more
specific.

If anyone uses django.get_version in a third party tool, the version
reported would again be a little more specific. I use a logger at
work that would have more accurate version strings in its logs, for
example.

That's all I saw this as -- a minor boost to the specificity of the
version string for those running off SVN without having to run svn
info.

Cheers,
deryck

Russell Keith-Magee

unread,
Aug 17, 2007, 9:49:10 PM8/17/07
to django-d...@googlegroups.com
On 8/18/07, Deryck Hodge <der...@samba.org> wrote:
>
> On 8/17/07, James Bennett <ubern...@gmail.com> wrote:
> > What does this accomplish that 'svn info' doesn't?
> >
>
> Well, nothing, really. :-)

I'm with Deryck - In reality, it achieves nothing that can't be done
easier with svn info, but I've had more than one discussion with an
end user asking them which version they are using, and being told
'0.97-pre'. Embedding an SVN revision in the version tag would
certainly slow down the rate at which I rend hair from my scalp :-)

So, +1 to the idea, but I'm not so happy with the implementation. In
particular, it relies on the availability of svn on the command line.

How can I put this delicately....

In my experience, the users that are most affected by this problem
also seem to be the users most likely to require their computers to be
defenestrated, so they are the users _least_ likely to have svn
available in their path.

Subtle enough? :-)

At the very least, your patch would need to catch the inevitable
error. Better yet would be an approach that doesn't require an
external call. Is there any other data source we can farm? Is there
anything we can easily glean from the contents of the .svn directory?

Yours,
Russ Magee %-)

Deryck Hodge

unread,
Aug 17, 2007, 11:31:11 PM8/17/07
to django-d...@googlegroups.com

On Aug 17, 2007, at 8:49 PM, "Russell Keith-Magee" <freakb...@gmail.com
> wrote:

When I looked at an admitedly small sample of the files in a few .svn
directories today, I couldn't see the pattern to the info, but you
would think it would be there. I don't mind poking at it some more
tomorrow or jumping on an svn IRC group or mailing list to ask how
best to get the latest revision if without svn tools.

As for handling the error, if you mean the error of svn not being on
the user's path, then what is there already handles that. The string
returned is the output of the command whether that output is the error
from not finding svn or the actual info we want. It's not like the
absence of the svn command will cause a Python exception.

I agree it's not ideal to do it this way, but I seem to recall from
some old viewcvs hacking that the command line tools or the Python svn
bindings were the only way to reliably get the revision info.

I just saw this as a not-perfect implementation that might help with
the most common case, but if we do think it's most likely that svn is
not on the user's path more often than not, then yes this patch would
be pretty pointless. :-)

Cheers,
deryck

Deryck Hodge

unread,
Aug 17, 2007, 11:31:47 PM8/17/07
to django-d...@googlegroups.com

Sean Perry

unread,
Aug 17, 2007, 11:37:14 PM8/17/07
to django-d...@googlegroups.com
On Aug 17, 2007, at 6:49 PM, Russell Keith-Magee wrote:
>
> At the very least, your patch would need to catch the inevitable
> error. Better yet would be an approach that doesn't require an
> external call. Is there any other data source we can farm? Is there
> anything we can easily glean from the contents of the .svn directory?
>

yeah, .svn/entries, should be line 4.

cat .svn/entries | head
8

dir
5920 <-- you want this
http://code.djangoproject.com/svn/django/trunk
http://code.djangoproject.com/svn

Deryck Hodge

unread,
Aug 18, 2007, 12:09:00 AM8/18/07
to django-d...@googlegroups.com

Certain (older?) versions of the entries file are XML. We would need
to figure out how many versions there are, which doesn't do much for
future proofing us.

This is one advantage the svn client has, but I'm really not against
parsing entries files ourselves. I just wanted to point out there are
pros and cons either way.

Cheers,
deryck

Collin Grady

unread,
Aug 18, 2007, 12:15:22 AM8/18/07
to django-d...@googlegroups.com
Deryck Hodge said the following:

> Certain (older?) versions of the entries file are XML. We would need
> to figure out how many versions there are, which doesn't do much for
> future proofing us.

Perhaps only fall back to the client if the 4th line isn't a rev #?

--
Collin Grady

Appearances often are deceiving.
-- Aesop

Graham Dumpleton

unread,
Aug 18, 2007, 12:51:35 AM8/18/07
to Django developers
FWIW, easier to use 'svnversion' command than 'svn info' and parsing
result.

Sean Perry

unread,
Aug 18, 2007, 1:47:21 AM8/18/07
to django-d...@googlegroups.com

First line is the format version number of the entries file itself.
Versions >= 7 are no longer in XML format. As you can see, mine says
'8'.

If it is XML, the structure should be:
<entries>
<entry revision="5920" blah blah/>
</entries>

Assuming I read subversion-1.4.4/subversion/libsvn_wc/README
correctly. The entries file format is documented pretty well in the
README. Should be trivial to get what django needs.

The joys of open source. The answers are pretty easy to find.

Deryck Hodge

unread,
Aug 20, 2007, 4:24:06 PM8/20/07
to django-d...@googlegroups.com
On 8/18/07, Sean Perry <sha...@speakeasy.net> wrote:
> First line is the format version number of the entries file itself.
> Versions >= 7 are no longer in XML format. As you can see, mine says
> '8'.
>
> If it is XML, the structure should be:
> <entries>
> <entry revision="5920" blah blah/>
> </entries>
>
> Assuming I read subversion-1.4.4/subversion/libsvn_wc/README
> correctly. The entries file format is documented pretty well in the
> README. Should be trivial to get what django needs.

Thanks, Sean, for the pointers on SVN files and suggesting the README.
Thanks to everyone else for all the suggestions.

I opened ticket 5215[1] and added a patch that parses
django/.svn/entries. This has been tested on systems with both the
new version of the entries file and the old. Both seem to work fine.
If the format of the file should change, this will start to return
'SVN-unknown' to give us a heads up. Actually, if anything goes wrong
(no entries file, a non-SVN working copy, etc.) this will return
SVN-unknown.

If I need docs or tests, please let me know. I wasn't sure on this
point since the version string didn't seem a major thing and not a lot
in terms of docs or tests is there now for it.

Cheers,
deryck

[1] http://code.djangoproject.com/ticket/5215

Adrian Holovaty

unread,
Aug 20, 2007, 11:12:38 PM8/20/07
to django-d...@googlegroups.com
On 8/20/07, Deryck Hodge <der...@samba.org> wrote:
> I opened ticket 5215[1] and added a patch that parses
> django/.svn/entries. This has been tested on systems with both the
> new version of the entries file and the old. Both seem to work fine.

Thanks for your work on this, Deryck! I've checked it in here:

http://code.djangoproject.com/changeset/5990

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

Reply all
Reply to author
Forward
0 new messages