[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New)(?) Subversion client user-agent string ugliness.

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 09 May 2011 12:47:22 +0100

On Mon, 2011-05-09 at 14:41 +0300, Daniel Shahaf wrote:
> Julian Foad wrote on Mon, May 09, 2011 at 12:17:43 +0100:
> > On Fri, 2011-05-06 at 21:47 -0400, C. Michael Pilato wrote:
> > > On 05/06/2011 07:08 PM, Greg Stein wrote:
> > > > On Fri, May 6, 2011 at 17:06, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> > > >> On Fri, May 6, 2011 at 4:01 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> > > >>> Is there a convention in HTTP user-agent strings to use whitespace to
> > > >>> delimit various bits of information carried in that string? I asked because
> > > >>> our client strings now look like so in trunk co:
> > > >>>
> > > >>> "SVN/1.7.0-dev (under development) neon/0.28.2"
> > > >>>
> > > >>> I *think* the " (under development)" bit is new(ish) and the result of
> > > >>> Julian's relatively recent tweaks to our version strings. I'm not so fond
> > > >>> of its appearance in this location, but wanted to hear other's opinion on
> > > >>> the matter.
> > > >>>
> > > >>> So ... what say you?
> > > >>
> > > >> Seems kinda redundant when used along with the '-dev' postfix in the
> > > >> version number, says I.
> > > >
> > > > Agreed. We should switch the User-Agent string from using SVN_VERSION
> > > > to SVN_VER_NUMBER.
> > >
> > > Okey dokey. r1100424. Thanks, guys.
> >
> > Good catch. Note that this consideration may affect the 1.6.x backport
> > proposal for r1084575, r1084581.
> >
> > ------------------------------------------------------------------------
> > r1084575 | julianfoad | 2011-03-23 13:15:11 +0000 (Wed, 23 Mar 2011) | 6 lines
> >
> > Change the descriptive version identifier text from '1.x.y (dev build)' to
> > '1.x.y (under development)' to help clarify that it's not merely a build
> > with debug symbols included or something like that.
> >
> > * subversion/include/svn_version.h
> > (SVN_VER_TAG): Change.
> > ------------------------------------------------------------------------
> > r1084581 | julianfoad | 2011-03-23 13:31:26 +0000 (Wed, 23 Mar 2011) | 11 lines
> >
> > Change the descriptive version identifier text from '1.x.y (under
> > development)' to '1.x.y-dev (under development)' to help clarify that it's
> > not merely a build with debug symbols included or something like that. This
> > is the second part of a change started in r1084575.
> >
> > * subversion/include/svn_version.h
> > (SVN_VERSION): Include the tagged version number before the parenthesis.
> >
> > * subversion/tests/cmdline/getopt_tests.py
> > (rep_lines_res): Adjust comment and regex for an optional "-dev" part.
> > ------------------------------------------------------------------------
> >
> > To avoid changing any programmatic uses of the version string, including
> > in the user-agent string, I recommend not backporting r1084581.
> >
> > danielsh, pburba: you both voted +1 for backporting both those revs.
> > Want to reconsider?
>
> The difference is whether off-the-branch builds will report themselves
> as "1.7.0-dev (under development)" or "1.7.0 (under development)"...
> No, I'm happy with both of my +1 votes.

Gah. I need to remember that the changes I made to the version strings
-- showing "-dev" and/or "(under development)" -- don't affect release
builds at all, and dev-build users are by definition deveopers/testers,
and therefore there is little concern about making such changes. That's
why it was a safe change in the first place.

I'll remove my veto.

If the changes happen to upset the validity of user-agent strings or
whatever, so be it: it doesn't really matter.

Sorry for the noise.

- Julian

> > Another option is also backporting r1100424, of course, but that seems
> > OTT as the problem of people misunderstanding/misreporting the version
> > is neither new nor severe.
> >
> > - Julian
> >
> >
Received on 2011-05-09 13:47:55 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.