On 8/8/06, Stefan Küng <tortoisesvn@gmail.com> wrote:
> Just updating individual files doesn't speed up anything at all. In
> fact, it can make things even worse. Fetching the status for a file
> actually fetches the status for the whole folder and all files in it,
> but then only the status of the asked file is returned (that's how the
> Subversion function works, unfortunately).
Really? Maybe I should ask Subversion dev list if this can be changed.
In the mean time, I still think it should be possible to limit the
TortoiseSVN status fetch to non-recursive status fetches, in only
those paths selected. It shouldn't take much logic to detect when
multiple files are in the same directory, and just run the status on
that directory once non-recursively (rather than recursively on each
and every unrelated sub-directory, as is the case now).
> And a full status update is necessary because you simply can't just
> guess what the status of files after an update is.
It's not "guessing" if you know the specific list of files/paths that
have just been updated. Also, the update operation returns status
changes (ADMCG). Couldn't that information be used to determine the
new status, or at least guess it with acceptable accuracy, without a
local status scan? :) Minimally, as I said before, you should be able
to limit status scans to just those paths directly affected,
non-recursively.
> You need to lock a file *before you start editing it*. That's the whole
> point of locking a file. If you just lock it before a commit, then the
> lock is useless.
> Maybe an "update-and-lock" is what you meant?
Why would you need to lock before editing, *if the file can be
merged*? What we want to do is lock the file (even though it can be
merged, in order to obtain a temporary exclusive commit status on that
file), immediately update it (in order to merge it with HEAD), deal
with any conflicts if necessary (including a full build/test cycle in
some cases), and then commit *last*. The current Commit operation
order imposes a kind of "Commit and pray" workflow on the user. This
"new" order of operations guarantees that there are no changes to the
files between the last Update and Commit action, and thus prevents the
"can't Commit, out of date" error, assuming the lock was not stolen or
broken. Locking after Update does not give the same guarantee, and
would require a redundant Update after the Lock is obtained.
We have the svn:needs-lock property set on all files that can't be
merged, so this workflow doesn't directly affect those files.
> > Why should they be
> > forced to update or refresh status on files that they absolutely know
> > have nothing to do with the commit at hand? Even the F5 refresh forces
> > them to wait for a full Status refresh on totally unrelated paths, and
> > wastes a huge amount of time on large WC directories.
>
> Just how much time are we really talking about here?
A full Update or Status-walk from WC root can take 15 to 45 minutes,
depending more on local workstation conditions than network or server
conditions. I think NTFS can take most of the blame here. Cleanup
operations take even longer. The largest directories are also the most
used directories, naturally, so they take a large percentage of this
total time. The "CODE" directory for example, where programmers live,
takes up to 5 minutes for any local recursive directory scan type
operation, including recursive Status refresh, or even Updates that
return no changes. The "ART" directory can take much longer to
traverse.
This is unacceptable for users who can see the list of files they
want to work with, right in front of them, yet are given no option to
limit operations to that list. This list is nearly always a very small
sub-set of the paths contained recursively under their root working
directory. In their mind, any operation on that visible set should
only take a matter of seconds per selected file, so they are upset
when it takes much longer than that. Users have been willing to put up
with the recursive Status scan to populate the dialog a first time,
but are much less willing to wait for the same scan a second or third
time.
> Those are not artificial interface limits, that's how Subversion is
> designed and works. To do what you ask for would mean to write an ugly
> workaround to the Subversion design.
I wholeheartedly disagree. Subversion does give you the option to work
with specific path lists non-recursively, rather than forcing you to
run every operation recursively on a base directory. The "--targets"
and "--non-recursive" command line options are examples of this. All
I'm asking is that similar path-specific operations be exposed through
existing TortoiseSVN dialogs, in an intuitive manner. As I have noted
before, right-click menu options in the TSVN Commit dialog already
expose path-specific actions, equivalent to "svn delete", "svn
revert", "svn lock", "svn diff", and even "svn log". I just want to
expand this list of path-specific actions to include "svn update",
"svn status", and "svn lock -m 'Commit Pending'; svn update".
As a side note, the "Check for modifications" dialog could use the
same additional right-click options for update, status, and
lock/update, except that I would also like to add a "Commit..." option
there.
:) Jared
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Aug 8 21:39:39 2006