Max Bowsher wrote:
>> 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.
> 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.
> 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.
>>> 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
> 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.
>> 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
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jan 8 19:58:36 2005