SteveKing wrote:
> Max Bowsher wrote:
> [snip]
>>> It's not to forbid a reliable client. It's to forcing users to update
>>> their clients (e.g. in case of a security bug in older versions or in
>>> this case to enforce a client which has certain features so users don't
>>> forget to enter an issue number, write a log message with a minimum log
>>> message size, ...)
>>
>> Personally, I don't think the server has the right to dictate versions
>> to the client.
>> Only to agree or refuse to the commit the client proposes.
>
> Ok, that's your opinion. Other users disagree with that, and I do too.
> If I were responsible for a Subversion server and I knew that there are
> client versions around which have either security bugs or other bugs
> which could harm the server, I'd like to be able to reject those
> clients. Sure, you could mail all the users and tell them to upgrade
> their clients, but you'll discover soon that most of them just don't do
> it.
How can a bug in the client harm the server?
And even if it could, pre-commit would be rather too late to check.
Besides I could be using an old client with a backported security fix.
>> Why not have the pre-commit check for the suitability of the log message?
>> If enter a valid log message in a client which doesn't force me to enter
>> a valid log message, the commit should still succeed.
>
> Because then the users complain about their commit being rejected. If
> the client can check/help with that before you even start the commit you
> can save time.
But the commit would only be rejected if they weren't using a helpful
client.
>> I still think that the SVN libraries are the user-agent, not whatever
>> happens to be guiding their actions.
>
> I don't see the point in a user-agent string which always tells
> "SVN/xxx" - every commit to a Subversion repository has to be some kind
> of svn client. Imagine that all webbrowsers would have the same
> user-agent string "Browser/XXX" - that would be pretty useless.
I guess "SVN/x.y.z (some additional settable string)" would be OK.
>>>> Logging the useragent of every commit into a revprop?
>>>>
>>>> My initial reaction is "yuck!".
>>>>
>>>> What real use could this data be put to?
>>>
>>>
>>> Think about a statistics page generated of a repository. Or do you think
>>> that all those web statistics which show the browser (type and version)
>>> with which the webpage was accessed are completely useless too?
>>> Sure, it's not something that's very important, but surely 'nice to
>>> have'.
>>
>> Yes, but that sort of statistics goes in a log file.
>
> But it can only go into a log file if the repository is hosted by
> Apache. It can't go there for svn://, svn+ssh//, file:/// - because
> those don't get a user-agent string.
>
>> To ruthlessly over-extend your metaphor, that would be like the
>> webserver appending the user-agent info in coded footers on the .html
>> files being served.
>
> Not really. Webpages are shown to the user. A revprop usually isn't.
I was envisaging the webserver not showing the footers to clients.
The point is, that transient data doesn't belong bound to permanent data.
>>> Also, revprops can be checked in a pre-commit hook.
>>
>> So can environment variables or command line parameters.
>
> That I don't understand. How can an environment variable or a command
> line parameter on the client side be checked by a pre-commit hook on the
> server?
It can't. But AFAICS, your suggestion of a revprop was just as a vehicle to
expose the information to pre-commit.
The server could equally well pass the information to the pre-commit hook as
an environment variable or command line parameter.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 8 20:29:22 2005