[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: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-05-20 15:44:32 CEST

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
> > not know what files will be committed at the time it would have to
> > the message template.
> >
> > 2) TortoiseSVN lets the user start typing their commit message while
> > 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

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
> poor performance of GUI's (which may specifically be due to poor O/S
> outside of the scope of Subversion _or_ the GUI's). We should certainly
> into account anything we can do to improve the performance, but if
> 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
> that should not, IMNSHO, be a driving considering in any design

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.


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

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.