kfogel@collab.net wrote:
> Don't think "network turnaround" automatically equals "bad thing"! :-)
Not automatically, but most times. Especially if you can't tell the user
what's really going on (are we just waiting for some data packets to
arrive, or are we transferring already? - Subversion still lacks fine
grained feedback of network activity).
> The classic problem with a network turnaround is that it introduces
> user-visible latency. However, in this case the second turnaround
> would happen outside user time, because TSVN would have already popped
> up the log message box earlier. Thus, there is no problem.
>
> In fact, you can make *both* network turnarounds irrelevant:
>
> 1. Pop up the log message window right away.
>
> 2. Then in the background, fetch the no-files-list template. Also,
> in the background start the wc crawl.
This would work if we don't get into a timeout problem. You see, if we
have to wait for the API to return from a timeout (there's no way to
stop the API from waiting), we would have to block the actual commit
until that thread finishes. If we don't wait for the thread to finish,
then the program will crash because handles won't be closed properly,
memory not freed, functions not exited cleanly.
> 3. If you got a template in step (2), present it to the user in
> some way, so that they know that the log message they're
> currently writing may need to be updated to use the template.
>
> And, if the user has not yet started typing anything, just
> insert the fetched template into the editor directly. That way
> users can do the intuitive thing (i.e., wait) if they know a
> template is coming.
>
> 4. When the wc crawl finishes, fetch the with-files-list template.
> If it does not match the no-files-list template, then notify the
> user of this, again in some interface-specific way. And as with
> step (3), if they haven't started typing yet, then just insert
> the template into the editing window directly.
>
> Frankly, I think this is a pretty intuitive interface, it Does The
> Right Thing, and it requires no local template storage and no special
> support from Subversion (other than the new RA function of course).
I know that for Subversion, just using the hook would be the easiest way
to go.
>>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.
>
> Okay, under some circumstances it can take a second. But the question
> is, is that a good enough reason to design an entire local-storage
> system for log message templates? That would add a huge complexity
> burden to Subversion, to solve just this one case.
I'm not sure why you think this would be a *huge* complexity burden.
TSVN already has locally stored log message templates implemented:
tsvn:logtemplate
http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch04s09.html
>>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.
>
> I was responding to your assertion that admins would not set up the
> template hook, by demonstrating that they have set up other hooks
> under similar circumstances.
I agree that admins would set up the script if they want log message
templates which are dynamic. But I go on a lim here and say that most
projects won't need dynamic templates but (if they even use templates)
are happy with static ones.
>>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)
>
>
> It's too early to decide this anyway, but just FYI: we shouldn't have
> the "-hook" on the end. That's an implementation detail. The client
> doesn't know or care whether the server uses a hook, a shovel, or a
> bacterium to produce the log message template. Something like
> "svn:log-message-template-method" would be the way to go.
No problem. Was just a suggestion ;)
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 21:22:52 2005