[lm-sensors] SVN/trac requests

[lm-sensors] SVN/trac requests

[Jean Delvare]

Hi Axel,

I have the two following requests with regards to lm-sensors' SVN/trac:

1* Can the "V-2-3-1" tag be renamed to "V2-3-1"?

2* We often need to ask people to try the latest version of
sensors-detect. For now we point them to:
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt

The problem is that this version of the SVN file doesn't have its
keywords substituted, so the version string reads:
  '$Revision$ ($Date$)'
This might become a problem in the long run when users report with this
version string, as we will be unable to tell what version of the file
they have. So, is it possible to ask trac to provide the file with
keywords substituted? I'm surprised this isn't the default...

Thanks,
-- 
Jean Delvare

[lm-sensors] SVN/trac requests

[Axel Thimm]

Hi,

On Tue, Sep 26, 2006 at 02:05:02PM +0200, Jean Delvare wrote:
> I have the two following requests with regards to lm-sensors' SVN/trac:
> 
> 1* Can the "V-2-3-1" tag be renamed to "V2-3-1"?

Yes, the contents of "tags" is (for svn) just another folder, so just
as you rename conventional files/folders under svn you ranme this one,
too, e.g. "svn mv V-2-3-1 V2-3-1; svn ci ." in the tags folder should
be enough.

> 2* We often need to ask people to try the latest version of
> sensors-detect. For now we point them to:
> http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
> 
> The problem is that this version of the SVN file doesn't have its
> keywords substituted, so the version string reads:
>   '$Revision$ ($Date$)'
> This might become a problem in the long run when users report with this
> version string, as we will be unable to tell what version of the file
> they have. So, is it possible to ask trac to provide the file with
> keywords substituted? I'm surprised this isn't the default...

Hm, I don't have a solution. First of all I wouldn't loop it through
trac, but use the direct svn URL instead, e.g.

http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect

But this has the same issue, so it doesn't solve the issue at hand.

I would guess that the keyword substitution happens at the client, and
svn/trac offer the raw contents only. :(
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060926/c63d34f6/attachment.bin 

[lm-sensors] SVN/trac requests

[Michael Renzmann]

Hi.

Axel Thimm wrote:
  > Hm, I don't have a solution. First of all I wouldn't loop it through
> trac, but use the direct svn URL instead, e.g.
> 
> http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> 
> But this has the same issue, so it doesn't solve the issue at hand.
> 
> I would guess that the keyword substitution happens at the client, and
> svn/trac offer the raw contents only. :(

Keyword substitution is disabled by default and must be enabled 
explicitly if wanted.

See: 
http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.keywords

Bye, Mike

[lm-sensors] SVN/trac requests

[Jean Delvare]

> Hi,
> 
> On Tue, Sep 26, 2006 at 02:05:02PM +0200, Jean Delvare wrote:
> > I have the two following requests with regards to lm-sensors' SVN/trac:
> > 
> > 1* Can the "V-2-3-1" tag be renamed to "V2-3-1"?
> 
> Yes, the contents of "tags" is (for svn) just another folder, so just
> as you rename conventional files/folders under svn you ranme this one,
> too, e.g. "svn mv V-2-3-1 V2-3-1; svn ci ." in the tags folder should
> be enough.

Yeah, it worked :) Thanks! I expected something more obscure. In fact I
didn't expect it to be possible from the client side. Now the only
drawback is that the timestamp on the renamed directory changed, but
that's a minor annoyance we should be able to live with.

> > 2* We often need to ask people to try the latest version of
> > sensors-detect. For now we point them to:
> > http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/detect/sensors-detect?format=txt
> > 
> > The problem is that this version of the SVN file doesn't have its
> > keywords substituted, so the version string reads:
> >   '$Revision$ ($Date$)'
> > This might become a problem in the long run when users report with this
> > version string, as we will be unable to tell what version of the file
> > they have. So, is it possible to ask trac to provide the file with
> > keywords substituted? I'm surprised this isn't the default...
> 
> Hm, I don't have a solution. First of all I wouldn't loop it through
> trac, but use the direct svn URL instead, e.g.
> 
> http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect

Then this is considered an external link by trac, which adds a special
icon in front of it. I linked to trac to avoid that.

> But this has the same issue, so it doesn't solve the issue at hand.
> 
> I would guess that the keyword substitution happens at the client, and
> svn/trac offer the raw contents only. :(

I guessed so, but trac could be seen as a client.

-- 
Jean Delvare

[lm-sensors] SVN/trac requests

[Jean Delvare]

> Axel Thimm wrote:
>   > Hm, I don't have a solution. First of all I wouldn't loop it through
> > trac, but use the direct svn URL instead, e.g.
> > 
> > http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > 
> > But this has the same issue, so it doesn't solve the issue at hand.
> > 
> > I would guess that the keyword substitution happens at the client, and
> > svn/trac offer the raw contents only. :(
> 
> Keyword substitution is disabled by default and must be enabled 
> explicitly if wanted.
> 
> See: 
> http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.keywords

Well we did enable keyword substitution for this file:
$ svn propget svn:keywords prog/detect/sensors-detect
Author Date Id Revision

And it works well on my side. What I would like is to get it to work in
trac, i.e. trac would serve keyword-substituted files rather than "raw"
files. Any idea how to do that, if possible at all?

Another option is to give the users a simple svn command to type to
retrieve just that file:
  svn export http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect

However it is significantly less convenient, as the user might not have
svn installed. Or maybe we can install a simple CGI script on the web
server which would run this command and return the result to the
user? I can't seem to find an option to output the file to stdout
though, which we would need.

-- 
Jean Delvare

[lm-sensors] SVN/trac requests

[Jean Delvare]

Quoting myself:
> Another option is to give the users a simple svn command to type to
> retrieve just that file:
>   svn export http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> 
> However it is significantly less convenient, as the user might not have
> svn installed. Or maybe we can install a simple CGI script on the web
> server which would run this command and return the result to the
> user? I can't seem to find an option to output the file to stdout
> though, which we would need.

Ah, it appears that "svn cat" does just that, so it could actually work.

-- 
Jean Delvare

[lm-sensors] SVN/trac requests

[Axel Thimm]

On Tue, Sep 26, 2006 at 05:43:46PM +0200, Michael Renzmann wrote:
> Axel Thimm wrote:
>   > Hm, I don't have a solution. First of all I wouldn't loop it through
> > trac, but use the direct svn URL instead, e.g.
> > 
> > http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > 
> > But this has the same issue, so it doesn't solve the issue at hand.
> > 
> > I would guess that the keyword substitution happens at the client, and
> > svn/trac offer the raw contents only. :(
> 
> Keyword substitution is disabled by default and must be enabled 
> explicitly if wanted.
> 
> See: 
> http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.keywords

But the file in question already has svn:keywords properly set.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060926/2bda417a/attachment.bin 

[lm-sensors] SVN/trac requests

[Axel Thimm]

On Tue, Sep 26, 2006 at 07:10:22PM +0200, Jean Delvare wrote:
> > Axel Thimm wrote:
> >   > Hm, I don't have a solution. First of all I wouldn't loop it through
> > > trac, but use the direct svn URL instead, e.g.
> > > 
> > > http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > > 
> > > But this has the same issue, so it doesn't solve the issue at hand.
> > > 
> > > I would guess that the keyword substitution happens at the client, and
> > > svn/trac offer the raw contents only. :(

> Another option is to give the users a simple svn command to type to
> retrieve just that file:
>   svn export http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> 
> However it is significantly less convenient, as the user might not have
> svn installed. Or maybe we can install a simple CGI script on the web
> server which would run this command and return the result to the
> user? I can't seem to find an option to output the file to stdout
> though, which we would need.

If no native solution in svn/trac is found maybe the scripts doing the
snapshots could extract this file w/ keywords and place it to a
canonical place?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060926/67d79b99/attachment.bin 

[lm-sensors] SVN/trac requests

[Jean Delvare]

Hi Axel,

> On Tue, Sep 26, 2006 at 07:10:22PM +0200, Jean Delvare wrote:
> > > Axel Thimm wrote:
> > >   > Hm, I don't have a solution. First of all I wouldn't loop it through
> > > > trac, but use the direct svn URL instead, e.g.
> > > > 
> > > > http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > > > 
> > > > But this has the same issue, so it doesn't solve the issue at hand.
> > > > 
> > > > I would guess that the keyword substitution happens at the client, and
> > > > svn/trac offer the raw contents only. :(
> 
> > Another option is to give the users a simple svn command to type to
> > retrieve just that file:
> >   svn export http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > 
> > However it is significantly less convenient, as the user might not have
> > svn installed. Or maybe we can install a simple CGI script on the web
> > server which would run this command and return the result to the
> > user? I can't seem to find an option to output the file to stdout
> > though, which we would need.
> 
> If no native solution in svn/trac is found maybe the scripts doing the
> snapshots could extract this file w/ keywords and place it to a
> canonical place?

This would imply up to 24h of delay before the user can pick the new
version of the script. I'm OK with daily snapshots for the project
itself, but sensors-detect is a bit special in that it helps us
investigating user problems, and being able to update the script with
new data and tell the user to try the new version the minute after is
very convenient.

I wouldn't bother if the script wasn't run by root. I'd make the file
available on my server and I'd tell the users to pick it there. But
from a security point of view, that sucks. I really want people to get
a file from lm-sensors.org. And I want the file to come right out of
the Subversion repository, with no man in the middle.

Thanks,
-- 
Jean Delvare

[lm-sensors] SVN/trac requests

[Axel Thimm]

Hi,

On Tue, Sep 26, 2006 at 09:23:00PM +0200, Jean Delvare wrote:
> > On Tue, Sep 26, 2006 at 07:10:22PM +0200, Jean Delvare wrote:
> > > > Axel Thimm wrote:
> > > >   > Hm, I don't have a solution. First of all I wouldn't loop it through
> > > > > trac, but use the direct svn URL instead, e.g.
> > > > > 
> > > > > http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > > > > 
> > > > > But this has the same issue, so it doesn't solve the issue at hand.
> > > > > 
> > > > > I would guess that the keyword substitution happens at the client, and
> > > > > svn/trac offer the raw contents only. :(
> > 
> > > Another option is to give the users a simple svn command to type to
> > > retrieve just that file:
> > >   svn export http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
> > > 
> > > However it is significantly less convenient, as the user might not have
> > > svn installed. Or maybe we can install a simple CGI script on the web
> > > server which would run this command and return the result to the
> > > user? I can't seem to find an option to output the file to stdout
> > > though, which we would need.
> > 
> > If no native solution in svn/trac is found maybe the scripts doing the
> > snapshots could extract this file w/ keywords and place it to a
> > canonical place?
> 
> This would imply up to 24h of delay before the user can pick the new
> version of the script. I'm OK with daily snapshots for the project
> itself, but sensors-detect is a bit special in that it helps us
> investigating user problems, and being able to update the script with
> new data and tell the user to try the new version the minute after is
> very convenient.

Indeed, stretching feedback cycles to 24 hours is ugly. :/

> I wouldn't bother if the script wasn't run by root. I'd make the file
> available on my server and I'd tell the users to pick it there. But
> from a security point of view, that sucks. I really want people to get
> a file from lm-sensors.org. And I want the file to come right out of
> the Subversion repository, with no man in the middle.

Still assuming there is no native way to ask trac/svn to add keyword
expansion, live cuts could be made by using svn's commit triggering
system instead of using cron.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060926/a629e43e/attachment.bin 

[lm-sensors] SVN/trac requests

[Michael Renzmann]

Hi.

Axel Thimm wrote:
> Still assuming there is no native way to ask trac/svn to add keyword
> expansion, live cuts could be made by using svn's commit triggering
> system instead of using cron.

As far as I know, Trac is not able of keyword expansion so far. However, 
I'll ask on #trac and see what I can find out about that.

The option with letting a commit trigger the "export script" came to my 
mind, too, when I read about Jean's reservation regarding a cron-based 
solution.

Bye, Mike

[lm-sensors] SVN/trac requests

[Michael Renzmann]

Hi again.

Michael Renzmann wrote:
> As far as I know, Trac is not able of keyword expansion so far. However, 
> I'll ask on #trac and see what I can find out about that.

Outcome: no support for keyword expansion at this time. Trac accesses 
the repository directly and would need to take care of the expansion 
itself (just as the svn client does).

See also:
http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/4133
http://trac.edgewall.org/ticket/717

Bye, Mike

[lm-sensors] SVN/trac requests

[Jean Delvare]

Hi Michael,

Michael Renzmann wrote:
> > As far as I know, Trac is not able of keyword expansion so far. However, 
> > I'll ask on #trac and see what I can find out about that.
> 
> Outcome: no support for keyword expansion at this time. Trac accesses 
> the repository directly and would need to take care of the expansion 
> itself (just as the svn client does).
> 
> See also:
> http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/4133
> http://trac.edgewall.org/ticket/717

Thanks for the investigation. Hopefully a future version of trac will
support keyword substitution. In the meantime, we can go with either a
commit-triggered script, or a CGI. I have a CGI working, it's really
simple:

---8<---
#!/bin/sh
# Let the users access the latest version of sensors-detect, with keywords
# substituted.

echo "Content-Type: text/plain"
echo

svn cat http://lm-sensors.org/svn/lm-sensors/trunk/prog/detect/sensors-detect
---8<---

Is there a problem with having this CGI running on the lm-sensors.org
server? Or is the commit-triggered approach prefered for performance
reasons? I don't know how to do commit-triggered scripts.

Note that if this is too much hassle, we can probably stick to the
current situation for some more time; the lack of keyword substitution
is only a minor annoyance.

Thanks,
-- 
Jean Delvare