Ivan-Assen Ivanov wrote:
>>> data). During the time in which you wait for a new server release, you
>>> can then only pray that all your users don't use that broken client
>>> anymore - not a very good scenario if you ask me.
>>
>> Or, you can implement appropriate checking in the pre-commit script.
>
> OK, so this is something I don't understand.
> How can you implement appropriate checking in the pre-commit script,
> if the pre-commit script doesn't have sufficient information to reason
> about it? Wasn't that the whole point of the original request of
> SteveKing, before you two got sidetracked into a theoritical
> discussion on client/server compatibility?
SteveKing wanted to check version in pre-commit, to protect against old
buggy clients from sending invalid data to the server.
I counter-proposed that version checking was undesirable, because it would
affect buggy clients even when sending correct data, and also affect clients
that would have been patched to avoid the bug.
Instead, pre-commit can check not for the version, but for the invalid data,
and reject *that*.
> To put it back to where it was: How can I, as a maintainer of a
> Subversion repository, and writer of a pre- and post-commit scripts,
> determine whether a particular commit attempt is coming from a user
> without the physical ability to adhere to the codebase standards
> established on this repository, (in this particular case, the
> requirement that all commits are related to issue numbers in the issue
> tracking system)?
Don't check whether the client has the capability, check whether the
incoming commit has the appropriate markings associating it with an issue
number.
> I can see how it is a good idea to _technically_ provide compatibility
> between various clients and servers. I fail to see how it is a good
> idea to explicitly forbid breaking compatibily as conscious decision
> on part of the server's administrator for _administrative_ reasons.
I'd rather help the administrator achieve the desired result (commits
conforming to certain policies), without needing to to break compatibility.
> What is the point of the user agent string anyway?
Not very much at all.
It exists only because such a thing is expected in HTTP.
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 00:09:42 2005