SteveKing wrote:
> 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).
I don't agree with that. I think the role of a developer is to create a
well-designed useful and maintainable system.
Sometimes, that includes questioning the users suggested design for
achieving something, and maybe doing things a better way instead.
>> 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.
But it's exactly the kind of piecemeal undesigned feature which we try
extremely hard to avoid.
The reason for the existance the of the user-agent header is purely because
it was inherited from HTTP. It's not supposed to have any real relevance to
Subversion.
Besides, suppose we were to change the user-agent string. What then, do we
do about svn:// access?
>> 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've explained already why rejecting versions is a poor approach due to
virtual certainty of false positives, and unnecessary encumberance on users.
Regarding the work... this entire broken data problem has a reasonable
chance of *never* happening again. And, if it does, then the community can
assemble a hook script and share it.
>> 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?
I actually find the statistics argument reasonably convincing - but I'd want
a solution which worked for ra_svn (and ra_local?) too.
However, the whole 'rejecting clients based on version' argument has opened
my eyes to the potential for abusing the feature, making me feel rather
disturbed about the whole idea.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 9 12:11:01 2005