Re: RFC: Log Message Templates via new hook.

kfogel@collab.net wrote:
> SteveKing <steveking@gmx.ch> writes:
>>You're right. That's why I suggested to not use a runtime param for
>>the hook script but a setting in the working copy (e.g. property,
>>server side configuration, inherited property, ...) which only states
>>if the hook script
>>- has to be called (if not, then the template is static and should
>>also be stored in the wc)
>>- has to be called with the complete file list (i.e. TSVN would have
>>to prevent the user from entering a log message until all files which
>>get committed are known)
>>- has to be called, but without a file list
>
> Sorry, I'm still not seeing what exactly this property would do, or
> rather, how it would help.
>
> Again, if TSVN must discover state (e.g., a property) in the working
> copy before it knows what to do for the log message interface, then it
> cannot present the log message editing window early the way it does
> now.
>
> This is because TSVN has to *find* that property first, and (in the
> extreme case) a full wc crawl may be necessary to do that. Remember
> that it may find multiple properties, and have to make some sort of
> resolution decision. So even if it finds one property, it has to keep
> crawling, unless there's a highest-always-wins algorithm.

But you have to remember that this crawling is much faster than a server
connection.

But I'll try to explain more clearly why I want this configured with a
property (or something else stored locally):

if no such property is available, then TSVN would have to either
- always pass --no-file-list to the hook script if we allow the user to
start typing the log message before the file list is known. This might
anger admins which want their users to follow the template generated
from the filelist.
- always prevent the user from typing the log message until we contacted
the repository. This definitely *will* get users angry which don't even
use log message templates (I know that, because the feature of typing
the log message before the file list is know was repeatedly requested,
and I got some angry mails once this feature didn't work properly).

So, whatever TSVN does without such a property, it will always make some
people angry.

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.

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).

> But I think this is all way, waaaay to much complexity for what should
> be a simple feature. Of course, TSVN can implement all of the above
> itself, requiring no special support from Subversion. I think it
> would not be good if TSVN did that, but I can't stop it from happening
> :-). All I can do is point out that there's no compelling argument
> for special support in SVN itself for any of this.

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).

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