John Peacock <jpeacock@rowman.com> wrote on 05/20/2005 06:11:20 AM:
Your comments are off the mark here John.
> > 1) With many GUI tools, at least TortoiseSVN and Subclipse, the GUI
does
> > not know what files will be committed at the time it would have to
request
> > the message template.
>
> >
> > 2) TortoiseSVN lets the user start typing their commit message while
the
> > code is crawling the WC looking for the changes.
>
> Both of these are basically the same thing: the two main GUI's are not
able to
> quickly create the actual full commit before the user gets bored. This
is a
> limitation of the GUI, since the CLI client has to do the same work, yet
I am
> not aware of anyone complaining that commits take too long to
preprocess.
No, they are not the same issue. #1 is not a performance issue, it is a
feature issue. Say you select the root of your WC and choose commit,
these tools will show you all modified files in a dialog, along with a
field to enter a commit message. That means we would have to fire the
hook prior to showing the dialog, and use the files we were going to show
in the dialog as what we passed to the hook. The problem is that the user
can then deselect some of those files to only commit a subset. A seconday
problem is that we also show unversioned files that are not ignored and
give you the option to include those in the commit. Those files would not
be passed to the hook at all. Of course the user could always use the Add
option before commit to remedy that problem.
> I don't think *any* solution should be primarily predicated on mediating
the
> poor performance of GUI's (which may specifically be due to poor O/S
performance
> outside of the scope of Subversion _or_ the GUI's). We should certainly
take
> into account anything we can do to improve the performance, but if
either
> server-hooks or inherited properties perform acceptably in the CLI, then
that is
> suffient. If the GUI's have speed issues outside of the scope of
Subversion,
> that should not, IMNSHO, be a driving considering in any design
discussion.
The performance problem here is Subversion, and the time it takes to
return the list of modified files, not the GUI. I do not want to
sidetrack the discussion here though. This wasn't about performance. The
issue is that the GUI, in this case TSVN, allows the user to start typing
their log message while it is still building the list of files to commit
-- in my opinion this is a good thing. To support this hook, TSVN either
has to drop this feature, which will upset its users, or call the hook
with an empty list of files. TSVN already supplies a mechanism for
inserting the list of changes files that takes into account the issues in
#1 and #2.
Finally, all I am asking is that we take into account ALL of the consumers
of the Subversion API before we make these decisions. I am not saying
that we need to make special consideration for the GUI's, just that there
needs ought to be factored into the equation.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 20 15:46:04 2005