SteveKing wrote:
> Max Bowsher wrote:
>> SteveKing wrote:
>>> A feature which is requested often on the TSVN mailing list is the
>>> ability to check the client version in a pre-commit hook.
>>> (the latest request was because they wanted to reject commits from TSVN
>>> clients which don't have the bugtraq features implemented yet)
>>
>> For the non TSVN users here, could you explain what these features are?
>
> Sure:
> TSVN introduced some properties which it uses to make it easier for
> users to enter issue numbers into a log message.
> The document describing this is located here:
> http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
>
> Other properties TSVN introduced and which users/admins make want to
> enforce a minimum TSVN version numbers are documented here:
> http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch04s09.html
>
>> Perhaps because I don't understand that, I can't see any reason to
>> forbid a client which can talk a compatible protocol from communicating
>> with a Subversion server.
>
> 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.
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.
>>> I've searched the mailing lists and found that this is already possible
>>> if the repository is hosted on an Apache server.
>>> (http://svn.haxx.se/dev/archive-2003-05/1680.shtml)
>>>
>>> Then I looked at the source where that agent string is set/sent:
>>> subversion/libsvn_ra_dav/session.c, line 659,660 (1.1.2 tag)
>>> ne_set_useragent(sess, "SVN/" SVN_VERSION);
>>> ne_set_useragent(sess2, "SVN/" SVN_VERSION);
>>>
>>> As it is now, another client can't change that string to something else
>>> (e.g. "TSVN/1.1.2"), so I'd like to request that this is changed into a
>>> define (which of course defaults to "SVN/"SVN_VERSION) but can be
>>> changed by a client when compiling/linking to the Subversion libs.
>>
>>
>> I don't think that a define can do that.
>
> Why not? You can write something like
> #ifndef SVN_AGENT_STRING
> #define SVN_AGENT_STRING "SVN/"SVN_VERSION
> #endif
> and then use SVN_AGENT_STRING in those two lines mentioned above.
> A client could then compile the Subversion libs with SVN_AGENT_STRING
> set to something else.
I read your previous email as speaking about a client which is compiled and
linked to pre-existing Subversion libs.
I still think that the SVN libraries are the user-agent, not whatever
happens to be guiding their actions.
>>> Even better would be if Subversion would allow to set revprops with
>>> every command that affects the repository. That way, a new revprop (e.g.
>>> svn:user-agent) could be written every time. This would also have the
>>> advantage that you could later check each revision and find out with
>>> which client is was made. And of course it wouldn't be restricted to
>>> Apache based repositories.
>>
>> 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.
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.
> Also, revprops can be checked in a pre-commit hook.
So can environment variables or command line parameters.
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 19:46:51 2005