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.
On Fri, 17 Aug 2007 14:45:01 -0500, "Deryck Hodge" <der...@samba.org> wrote:
> 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.
> 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.
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."
On 8/17/07, James Bennett <ubernost...@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.
On 8/18/07, Deryck Hodge <der...@samba.org> wrote:
> On 8/17/07, James Bennett <ubernost...@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?
> On 8/18/07, Deryck Hodge <der...@samba.org> wrote:
>> On 8/17/07, James Bennett <ubernost...@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?
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. :-)
> On 8/18/07, Deryck Hodge <der...@samba.org> wrote:
>> On 8/17/07, James Bennett <ubernost...@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?
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. :-)
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?
> 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?
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.
> 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 #?
> 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.
> On Aug 17, 2007, at 10:37 PM, Sean Perry <sha...@speakeasy.net> wrote:
>> 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?
> 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.
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.
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.
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:
