Re: Adding SVN revision identifier to version

2007-08-20 Thread Adrian Holovaty

On 8/20/07, Deryck Hodge <[EMAIL PROTECTED]> 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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Sean Perry

On Aug 17, 2007, at 9:09 PM, Deryck Hodge wrote:

>
>
>
> On Aug 17, 2007, at 10:37 PM, Sean Perry <[EMAIL PROTECTED]> 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?
>>>
>>
>> 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.
>

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:

   


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.




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Graham Dumpleton

FWIW, easier to use 'svnversion' command than 'svn info' and parsing
result.

On Aug 18, 5:45 am, "Deryck Hodge" <[EMAIL PROTECTED]> 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.
>
> http://dpaste.com/17141/
>
> Cheers,
> deryck


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Collin Grady

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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Deryck Hodge



On Aug 17, 2007, at 10:37 PM, Sean Perry <[EMAIL PROTECTED]> 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?
>>
>
> 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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Sean Perry

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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Deryck Hodge



On Aug 17, 2007, at 8:49 PM, "Russell Keith-Magee" <[EMAIL PROTECTED] 
 > wrote:

>
> On 8/18/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>>
>> On 8/17/07, James Bennett <[EMAIL PROTECTED]> 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. :-)

Cheers,
deryck


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Deryck Hodge



On Aug 17, 2007, at 8:49 PM, "Russell Keith-Magee" <[EMAIL PROTECTED] 
 > wrote:

>
> On 8/18/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>>
>> On 8/17/07, James Bennett <[EMAIL PROTECTED]> 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. :-)

Cheers,
deryck


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Russell Keith-Magee

On 8/18/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On 8/17/07, James Bennett <[EMAIL PROTECTED]> 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 %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Deryck Hodge

On 8/17/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 8/17/07, Deryck Hodge <[EMAIL PROTECTED]> 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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread James Bennett

On 8/17/07, Deryck Hodge <[EMAIL PROTECTED]> 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."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Adding SVN revision identifier to version

2007-08-17 Thread Dave Rowe



On Fri, 17 Aug 2007 14:45:01 -0500, "Deryck Hodge" <[EMAIL PROTECTED]> 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.
> 
> http://dpaste.com/17141/
> 

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


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Adding SVN revision identifier to version

2007-08-17 Thread Deryck Hodge

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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---