On 16.06.2010 21:40, Bert Huijben wrote:
The plan is to remove even more expensive members from svn_wc_status3_t, to
make it just return cheap information. (I think working_size is available,
so we can add that specific one; but the scan if the file has been modified
on disk will be removed).
Huh? The scan whether a file was modified gets removed? Then what is the
status call for if not to get the text and property status?
If you really want an API which returns less info faster, please create
a new API for it (or a flag in the svn_client_status() call to omit the
more expensive checks). But seriously: whether a file is modified *is*
the status of a file. If you remove that info, it's not a status API
anymore but a 'svn_client_fastWcInfo()' or something like this.
I think having svn_client_status() not return that information would
lead to much confusion about the term 'status'.
The plan is to introduce a new svn_client_status_t structure (for
svn_client_status) which will have more data then the svn_wc_status3_t
structure, but we haven't started on that one.
The assumption here is that users of the libsvn_wc api want direct access to
the working copy without any performance penalties they might not want.
(E.g. not scanning the file for changes, or parsing all the conflict
details)
I get that. But I suggest adding a separate API for this and not cripple
the svn_client_status() for this. Status info means getting the info
about which files are modified. That's what every svn user expects when
talking about the status. So the API has to honor that.
If you want a way to get less info faster, please create an API with
another name for this.
On the other side: users of the libsvn_client api wants to have access to
the direct usable combination of data, which might give less performance.
Yes, something I need to in some situations. But I'd like to have this
information returned in one call if possible. Sure, I can now get the
info I need in two or three svn API calls. But that means that to get
the info, the wc is crawled three times instead of just once. And every
time files are touched which is very expensive on Windows.
The svn trunk now is a *lot* slower accessing the wc info than 1.6.x,
and even if that gets better (hopefully soon), forcing me to use three
API calls instead of one means an even worse slowdown. Even if trunk was
as fast as 1.6.x, with those API changes it will take three times the
file accesses and crawls to get the same info as before.
For example, to get the same info as with a status call before, I now
have to first get the status, then fetch the svn:needs-lock property on
every file separately. You can guess that this is a performance hit I
simply can not accept. That means I lose an important feature in TSVN,
something I'm absolutely sure many users will get very angry about.
Also keep in mind that locking is one of the features of SVN that the
other (distributed) version control systems don't have, so that's one of
the important things users choose svn over those.
Loosing that information (the svn:needs-lock info) or getting a severe
performance hit fetching it another way is just very bad. SVN should
make the features it stands out from the others make work well, not
worse. Or it will lose one of the most important advantages it has.
What I'm trying to say here: please don't cripple existing APIs but
create new ones with new names, and have APIs that return the same info
as before without a performance hit.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
