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.
Cheers,
deryck
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
What does this accomplish that 'svn info' doesn't?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
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
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 %-)
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
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
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
Perhaps only fall back to the client if the 4th line isn't a rev #?
--
Collin Grady
Appearances often are deceiving.
-- Aesop
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.
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
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