John Peacock <firstname.lastname@example.org> wrote on 05/20/2005 10:12:58 AM:
> Mark Phippard wrote:
> > No, they are not the same issue. #1 is not a performance issue, it is
> > 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.
> If the performance was not an issue in the first place, why was the
> asynchronous log message feature added in the first place?
Performance is not related to my point #1. You are correct that is
related to point #2. Please re-read if necessary. Point #1 is about a
valid feature that the GUI provides.
> > The performance problem here is Subversion, and the time it takes to
> > return the list of modified files, not the GUI.
> Again, I'd love to see someone point out users of the CLI complaining
> about how long it takes to bring up the editor during a commit.
I think there have been plenty of complaints about the performance of svn
status on Windows. This is nothing new.
> > Finally, all I am asking is that we take into account ALL of the
> > 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
> > needs ought to be factored into the equation.
> And I fully agree. I'm only saying that the core design must not be
> vetoed by a thirdparty extension that conflicts with improvements to the
> core API.
I am not vetoing anything. I am simply trying to bring the concerns of
the GUI's into the design discussion. Certainly those concerns deserve to
be raised? Ironically, I thought I was also advocating the same solution
as you -- adding inherited properties, and then driving this and other
feature off of properties.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 20 16:19:10 2005