On 8/9/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
> "limit status scans to affected paths" - ok, try to understand here:
> fetching the status of a single path is very expensive (see 'bug' report
> above). Imagine you did an update/commit of 100 files, your working copy
> consists of 10000 files in 100 folders. Fetching the status for those
> 100 files would be the same as fetching the status for the whole working
> copy. (assuming all 100 folders have the same amount of files in them).
I understand what you're saying, but you don't seem to understand the
importance of my emphsis on *non recursive* status checks. You seem to
have ignored this line entirely: "It shouldn't take much logic to
detect when multiple files are in the same directory, and just run the
status [fetch] on that directory once non-recursively".
Your example is not appropriate to our more common situation. A
better example would be a the same working copy, with 10K files in 100
folders. Let's say that the 100 files are being committed, as in your
example, but all those files are contained in only about 5 folders
total, speaking non-recursively. You should be able to do a "svn
status <5-folder-list> --non-recursive" check in those 5 folders
alone, and thus avoid wasting time of doing the same status check on
95 more unrelated folders. That's a 95% reduction in status check
time! And this is *before* they 'fix' the single-file status overhead
'bug'! After they implement the 'fix', if ever, you should be able to
attain even more time savings, and to eliminate the logic that
determines the list of 5 folders to scan. The same interface changes
will be required for this optimization both before and after any svn
sub-system 'fix'.
> I don't know how you're working in your project. But it really seems you
> should better change your project a little.
That's right, you don't know my project. So stop trying to dictate
policy via seemingly arbitrary interface choices. Yes, I said
"arbitrary". Given the non-recursive status fetch optimization
mentioned above, I don't see how "update" and "status refresh" are any
different from the existing options "revert" and "lock".
> If you need to lock a file so you can merge/resolve conflicts/commit
> without anyone else committing in the mean time, then maybe you should
> try to improve the communication in your team.
Wasn't the lock message always intended as a form of communication?
That is the whole point of this form of temporary locking! The lock
"communicates" the fact that a user has specific files in a commit
cycle, with a descriptive message, in a more direct and efficient way
than IM or e-mail circles, or even yelling. :) I see no reason this
communication has to be external to the SCM system. Many commercial
SCM systems integrate IM-ish messaging functions for the same reasons.
Having that communication linked directly to SCM operations on the
affected paths seems much more efficient than spamming "all interested
parties", whether they are dealing with those files at the time or
not, just in case they *might be* temporaly affected. With this
workflow, users interested in those files will be able to glean
commit-cycle status in real-time; all without wasting time, energy, or
lungs on external communications mediums.
> Several people working on
> the very same files at the same time usually means destroying each
> others work, or the files contain too much functions/methods/classes and
> require splitting up into several files.
"Usually" is not nearly the same as "always". In our time-tested case
(approaching one year now, with heavy daily development from over 30
high-activity users), the more appropriate word for the situation you
are describing is "rarely". Our development environment is obviously
much different from yours. It's a big world, after all. ;)
> You told earlier that your working copy is about 16GB, 190000 files,
> 90000 folders. If that working copy takes you 15 to 45 minutes, you
> either have a harddrive from the last century or your working copy
> resides on a network share and not your local harddrive. I can't believe
> that on a normal local harddrive it would take that much time for a
> status scan.
I don't need you to believe it for it to be true. We are all
standardized on 160GB or 250GB WD SATA-I hard drives, in a 2-disk
RAID-1 configuration. Criticize my hardware all you want -- that
doesn't change the fact that the interface and status fetch changes I
propose here would save time on ALL hardware. Thus, hardware
performance is not a valid debate issue in this thread, because all
hardware is equal in this regard. It is better to speak in terms of %
change in performance, before and after software changes, on the same
hardware.
> If you really have your working copy on a network share, then I suggest
> to change that instead of implementing ugly hacks into TSVN.
The WC is not on a network share. I would have mentioned that. And do
you really think adding a couple of intuitive options to the
Right-Click context menu, that directly correspond to existing svn
commands, in key dialogs, is an "ugly hack"?! No, the REAL ugly hack
is forcing users to glean file names on their own, put them in a
"--targets" file, or to write them manually on a command line.
Suitable GUI interfaces already exist in TortoiseSVN, and all they
need is a few more key right-click options. That is the situation
today, and it is UGLY.
> Select the files you want to commit, right-click, choose "commit".
Ay, there's the rub. You can't do that when the files you want to
select are under separate directories, can you? Windows File Explorer
has no option to display file contents of a folder recursively, that I
know of. Also, file selections are not persistent after changing
folder selections. If you know of such an option, that would make me
happy, but it still wouldn't change the Status refresh performance
issues we are talking about.
[Stefan's reply to Rob Conde's request]
> I'd say we postpone this issue until Subversion 1.5 is out. Because it
> will have some new API's which deal with changesets. And with those,
> there's more reason to keep the commit dialog open than we have now.
I would say the only reason needed for the "keep alive" option now is
the existence of the "Can't commit, newer version" error. While the
Changelist features would certainly be another fix for Rob Conde's
subset-per-commit issue, the "keep alive" option would definitely be a
quicker fix, and multiple fix options are always nice. :)
Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Aug 11 05:03:37 2006