John Peacock wrote:
> Very much so; I am not trying to stifle discussion. I'm just concerned
> that the discussion not get into "TSVN does this now and your new
> feature breaks it" and rather moves in the direction of "this new
> feature is less optimal for TSVN because of X, how can TSVN do things
> differently or how can we tweak the original feature to make it easier
> for TSVN to maintain its own feature?"
The problem is not *how* TSVN does things, it's *why* it does things as
it does now. You see, TSVN is a windows client, and therefore suffers
from the very bad performance from NTFS. So TSVN had to implement some
'features' to make at least the user experience better, even if the
whole performance can't be improved.
The 'feature' of TSVN where the user can start writing the log message
while the list of files to commit is fetched really is necessary. I'm
sure you've heard of users complaining that SVN (*not* TSVN) needs ten
minutes after a 'svn ci' until something is sent over the network. That
happens for users who have really big working copies (e.g. having the
boost library in their own repository). Linux is a lot faster here, but
Windows has NTFS which really sucks here.
So, imagine a GUI user, wanting to start a commit, but then the dialog
just sits there for ten minutes. The least we can do is offer the user
to make use of that time to write the log message.
I think if there weren't any good GUI clients on windows, you guys would
be more aware of the performance problems on windows, because then users
would complain on your mailing list a lot more.
> For example, it would seem worthwhile to have TSVN behave in exactly the
> same manner as now. If, during the creation of the execution of the
> commit to the repository a custom log-template is required, then TSVN
> can pop up a new requester informing the user of the template
> requirement and offer to:
>
> a) override the proposed template with the already entered message
> b) append the existing message to the end of the proposed template and
> give the user the opportunity to revise
> c) drop the message and start from scratch
>
> (with 'b' being the most sane default).
>
> I just want to make sure that all the assumptions be considered: on the
> part of the GUI authors as well as the CLI users and base API.
Sure, that would be a possibility. But I can already see users
complaining: they just wrote a very thorough log message which took them
some time to write. Now they can just throw it away? Or re-edit it
(which is basically the same)?
But there's another way to go here:
- have a log message template stored somewhere in the working copy
(inherited property, normal property, ...) which a client can use.
- that property can either be a complete log message template, or have a
special value which indicates that the repository has to be contacted.
- That special value also indicates if the change-files-list has to be
sent to the server or not
That way a client (GUI or CL) can decide depending on that locally
stored information what's best (at what time in the GUI-process to
contact the repository). And repo-Admins can choose if they really want
their users have to accept additional network turnaround or if it's
enough to have a static log message template.
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 20 17:51:00 2005