C. Michael Pilato wrote:
> All Greg was saying is that even when sending changes to the server,
> Subversion doesn't know the total size of the dataset at the start of
> the 'svn commit' operation or within an user-unnoticeable amount of
> time after the start of that operation, as it could take significantly
> long to crawl the working copy looking for changes.
Ok, I see. But in that case, having the client know what operation is
currently going on would help too. Something like
"gathering information to send"
and then later
"sending contents: 3.4 kBytes sent at 0.2 kBytes/s"
> I'll add that even after the crawl it doesn't know the size of the
> transmission, because while some stat() calls across the files in the
> committables list would reveal the size of those files, the size of
> the delta transmitted for each file is another matter completely. I
> find progress meters that appear to be showing linear progress across
> a workset but in fact update "jumpily" and misproportionally to be
AFAIK Subversion stores the delta in a tempfile before committing, so
the size should be known.
How the various UI clients handle the additional information is up to
them. I'm sure they'll handle this in a way that's not jumpy or annoying
but provide valuable information to the users.
>>And it might help a lot if just the number of bytes already
>>transferred could be shown (so the user know that *something* is going
>>on), even if the total amount isn't known.
> I can see that being at least somewhat useful, but would again suffer
> the same delay while committables are harvested, and again during
> post-commit operations.
Also see issue #901 which has been open for a long time now:
(personally, I think it's been open too long now ;)
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jul 15 10:06:32 2005