[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Log Message Templates via new hook.

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-05-27 20:41:29 CEST

kfogel@collab.net wrote:

> Did you not see my proposal for a third way, that would allow TSVN to
> solve this without requiring any special properties? It's in:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=100709

Yes I did. But this solution would even require *two* network turnarounds!

> By the way, a wc crawl would not be noticeably faster than a
> no-files-list round trip to the server in most cases, I believe. One
> network turnaround can happen quite quickly.

It *can* happen quickly. But depending on what authentication module
you're using and of course your internet connection, this can take up to
several seconds. Even if you're on a LAN, if you use mod_auth_sspi to
authenticate against a windows domain (which many users do on windows!)
then the authentication alone takes about a second.

Also, I've experienced network timeouts several times already when
trying to commit changes to TSVN. I don't think it has something to do
with the server (you know that it's fast enough ;) ), but with my ISP.
The bad thing about such a timeout is that the subversion API functions
don't return until the timeout really happens (and that's on my system
here about three minutes).

>>both options won't make our users very happy. Especially if you think
>>about the hook script won't be used by much repo admins (considering
>>they have to update their server first), also many projects will be
>>happy with static templates and don't need the magic hook script.
>
> Are you sure? Consider the 'pre-revprop-change' hook. I think most
> repositories set that up, so people can change commit messages, and
> yet it is *not* enabled by default.

The 'pre-revprop-change' hook isn't something that is called by the
client *before* the actual commit. So the authentication has to be done
only once (see my timing considerations above), and it has to be done
anyway so the added time isn't even noticed by the user.

>>So, I'd like to have the admin decide if TSVN (or other GUI clients)
>>can allow the user to start typing the log message, if typing isn't
>>allowed at all until the filelist is known, or if typing is allowed
>>but the hook script still has to be used (with the --no-file-list
>>option).
>
> Again, the third-way solution solves this.

Sure, but it would be slow - sometimes *very* slow. And for users of
GUI's even a second where the GUI doesn't 'respond' is annoying.

>>Sure, if Subversion won't implement such a property (or whatever other
>>means), then TSVN will have to define its own property for that (as we
>>already do with a lot of other options, since Subversion still lacks
>>server side configs passed to clients).
>>
>>But still, I think it would be better if Subversion would at least
>>*define* such a property, so all GUI clients can use the same property
>>(and it would be documented by Subversion, so really all clients know
>>that such a property exists and not every client implements its own
>>property).
>
>
> Agreed. I think it would be fine for us to reserve a new "svn:foo"
> property for TSVN (and other clients) to use, whether or not
> Subversion itself does anything with that property.

That would be great! May I suggest:
name: svn:log-message-template-hook
values: none (no server round trip)
         static (ask server, but without file list)
         full (ask server with full file list)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 20:43:16 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.