Re: Request: make the user agent string a define

Ben Collins-Sussman wrote:

>> Can we just say that many people would like to know (for whatever
>> reasons they have, wheter you agree with them or not) with which
>> client users connect to the repository and leave it at that?
>
> The truth is, that's just not the way the Subversion project works.
> Perhaps it's a philosophical difference between the Subversion and TSVN
> projects.
>
> My impression is that TSVN has a pragmatic style of development: "if
> lots of users ask for it, then it must be something useful, and
> therefore it must be something Good and worth doing."

It's not "... then it must be something useful" but "then it's a feature
we should offer, whether we think it's useful or not". It's not up to us
devs to decide what users need but to do what they want (of cource, it
it doesn't break something else or would create some other risk).

> But in the Subversion project we don't believe that. If we hear many
> requests for something, we still want to debate the merits of the idea,
> offer counter-solutions, and generally consider the impact of such a
> feature on the software overall. (For example: we won't implement the
> $Log$ keyword, even though people ask about it all the time.)

And that's reasonable. You explained why that $Log$ keyword would be
dangerous, that's fair enough.
But as for changing e.g. the user-agent string, that's not dangerous at
all, is easy to do (I guess it would take a Subversion def 5 minutes to
change that into a define) and would definitely _not_ break anything else.

> So your request above doesn't make a lot of sense to us: in our minds,
> popularity alone isn't a strong argument for a new feature. We refuse
> to say, "well, people have their reasons" and then forget about it.
> That's why you see Max and Erik trying to understand *why* users are
> asking for the feature.

I've explained the 'why', at least I think I did. It's just that I'm
getting tired of explaining things over and over again. For example, to
write a letter, I'd like to use a program with certain features. Even if
I know that I could use e.g. notepad or even a simple pencil for that task.
The same applies to those other solutions people here offered: write a
hook script that checks for that specific bad data and reject that
instead of a specific client: that would mean every time you discover
such a bug you have to write a completely new hook script. If I could
reject that certain client, I could use the same hook script and just
adjust the client version strings I'd like to reject.

> I really hate the fact that we so often end up getting into stubborn
> arguments with you, Steve. We certainly have no ill will towards you,
> no matter how it may appear. (I think TSVN is fantastic, and I love the
> work you do!) I'd love to see more and more collaboration between
> Subversion and TSVN. Don't let these debates frustrate you. :-)

Ok, so I'll try again explaining why I'd like the feature (put aside
_how_ it's done, I just want to check the client and version on the server):

- rejecting clients based on their version number.
   - rejecting because a specific client has a bug
   - forcing users to upgrade (_very_ useful in companies. That way you
don't have to go to each developers workstation and tell them again and
again to update). Sure, old clients would work too, but if you have to
support even very, very old versions of clients which you know have a
lot of bugs which are fixed in newer versions, you'd like to force your
users to update the clients.
   - rejecting 'too new' clients before the admin had the chance to test
those with his own server.

- building statistics (that's why _I_ want that feature)
   - with which clients do my users connect to the repository?
   - which is the most used client program?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org