John Peacock wrote:
> Folker Schamel wrote:
>> Status and commit of a larger tree cost the same time
>> with TSVN and with command line SVN on windows.
>
> Then why does TSVN put the cart before the horse and bring up a
> requester to create the log message before the commit is ready?
Because crawling the WC is slow on Windows. This is a know performance
problem with NTFS which means that AFAIR Windows is 2-3 times slower
than *nix would be.
> Why
> have I _never_ seen a CLI user complain about the length of time it
> takes for the editor to come up during a commit?
Because most Windows users will use a GUI client in preference to the
CLI. That's just the way Windows is and the way Windows users are, no
comment on which is better.
> Granted I haven't
> been reading the users list in a while, but I'm fairly confident that
> only
> the TSVN (and possibly Subclipse) users have this concern about
> performance.
>
> Here's a test:
>
> 1) Check out the same tree twice
> 2) Make the same changes in both trees (preferrably deep so there is
> some serious tree-walking going on)
> 3) Commit once using the standard Windows Subversion CLI and time how
> long it takes before the editor pops up
> 4) Do the same thing in TSVN and wait until the filelist is complete
> 5) Tell us what you found
TSVN uses the subversion libraries, period. It hasn't invented it's own
slow way of doing the same thing. It is executing the same code as the
CLI to walk the tree.
> I'm not saying that it shouldn't be taken seriously. I'm only saying
> that the non-standard way that TSVN has chosen to implement commits
> should not force the rest of the user base to accept a poorer
> implementation.
TSVN is not just a GUI front end for the CLI. It does things that the
CLI cannot do, the commit dialog being a good example. The TSVN Commit
dialog is not directly equivalent to the command line commit. It does a
status crawl first to present you with a list of changed files and you
can select which ones to include in the commit. You can also opt to
show unversioned files and select any of them for adding to the commit.
When you have selected the files and prepared the message, then you hit
[OK] TSVN does the commit. This sort of interactivity just isn't
appropriate to the CLI, but it is what makes the GUI clients popular.
Neither way is right or wrong, they just take different approaches. You
cannot state that the CLI is "standard" and everything else is "an
add-on". They are both subversion clients using the same library. OK,
the CLI is standard in as much as it is a part of the subversion source
base, and runs on every OS.
> While I agree that it should be taken into account, but
> I violently disagree that a feature for an add-on should drive
> development of the core project.
That is putting it a little strongly. The GUI clients should certainly
not drive anything, but they do have (almost) as much validity as the
CLI.
Simon
--
___
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:16:35 2005