> Alvin Thompson wrote:
>
>> please reread that thread. basically, since it is essentially a branch
>> of Tortoise CVS, it uses much of the same code. since cvs doesn't have
I have to object here: TSVN doesn't use the same code as TCVS at all!
Yes, we used TCVS as an inspiration on how the program should work, but
that's all. There's basically _nothing_ left from the TCVS code in TSVN.
I can see that you really want such a feature in svn, but by spreading
lies about other projects (or just your simple ignorance about the
project and just assuming things) won't help at all.
>> to worry about pristine copies or (usually) large numbers of files in
>> the .cvs directory, it uses a simple recursive algorithm when scanning
TCVS can only check if a file is "modified" by comparing the filedates.
Sure that is faster, but also very inaccurate. Subversion does a much
better job in that: if the filedates are different, it compares the file
with the base and determines this way if the file is actually modified
or not.
>> make more sense to implement this than to require that every other
>> program on the planet be SVN aware?
You say "every other program on the planet" but you actually mean only
one single program of thousands.
makl wrote:
> After that you will see that the performance problem has nothing to do
> with the size of the .svn area.
That's only partly true. Sure, the *size* doesn't affect the performance
at all, but the number of files does. So by using *one* compressed file
instead of several small files in the .svn folder the time to fetch the
status would go down (at least on windows). If you do some profiling you
can see that the most time is spent in the CreateFile() API to open a
file - reading the file contents, parsing and the rest is just a small
part of the time.
I don't know if reducing the number of files in the .svn folder would
affect the speed on Linux systems though.
Stefan
---
Build a man a fire - keep him warm for a day, set a man on fire - keep
him warm for the rest of his life.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 21:10:42 2004