Molle Bestefich wrote:
> See above point on the UUID.
> Whenever log messages are needed, we'll just fetch from
> top-most-cached --> HEAD then.
>
> In case of error such as...:
> - UUID changed
Can't happen. If the UUID changes, then the cache won't be found
(because we have to store the cache by the UUID) and therefore the log
is fetched automatically again.
> - No such revision as top-most-cached (cache invalid)
Not invalid but incomplete.
> - top-most-cached message doesn't match message just fetched from
> repo (repository replaced by other repository [a dump from a
> "branched" repo] with same UUID -or- hook is in place and someone
> changed the message
You can also change a log message from far in the past. Just checking
the HEAD revision isn't enough. Either we assume that logmessages can't
be changed or we fetch the logmessages every time like we do now.
To overcome possible log changes with the hook script in place, there
would be a button to invalidate the cache.
>>But there's one problem: the log can be shown for the wc root, but also
>>just for individual files. It can be shown up to the first copy
>>operation or for a date range.
>
> Retrieve the entire log from the root of the repository and filter it
> ourselves, of course.
> The idea would be to avoid the network roundtrip, and especially to
> avoid the searching through revisions to find log messages which
> Subversion does, and which it obviously does in a very, very slow
> manner.
That's not quite true. The most time when fetching a log is spent
connecting/authenticating with the server. This is especially true for
Subversion servers < 1.1.1, and will be until the next neon version
comes out (or someone patches the neonconfig.hw file for the Subversion
windows build like TSVN does now). The reason is a compile time switch
in neon which isn't set for windows (HAVE_SETSOCKOPT). That switch makes
neon faster because it reduces the wait time for connections.
Once this is done, the actual log is fetched very quickly!
>>If we would do such a cache, we would have to
>>- store it somewhere. The registry isn't really an option for such big
>>data amount (e.g. the Subversion log from HEAD to rev 1 uses about 7MB)
>
> Store it in memory.
Bad idea. Caching in memory would mean to fetch the log every time TSVN
starts up again (which is basically every time you start e.g. the log
dialog). So that would be useless!
> Cache it to disk to avoid any startup delay. Exactly like TSVNCache does.
We would have to write the cache to disk, yes.
>>- always fetch the log from the repository root, which requires another
>>round trip to the server and therefore takes more time than just
>>fetching a log of e.g the last 100 messages
>
> What? No.. We would always have *every* message in the repository cached.
> Only go back and fetch from top-most-message-in-cache --> HEAD message
> from server. It does require a roundtrip to the server, but it's my
> feeling that pulling 1 or 2 log messages from the server doesn't
> really take any time.
Repository root != HEAD
The repository root is e.g. https://svn.collab.net/repos/tortoisesvn
(where the repository is located, stripped off every path inside the
repository).
HEAD is the most current revision and has nothing to do with the
repository root.
Example: a user want's the log of the file wcroot/dir1/dir2/file1.txt
TSVN then has to do:
- get the UUID of wcroot/dir1/dir2/file1.txt (fast)
- find the url corresponding to wcroot/dir1/dir2/file1.txt (fast)
- find the repository root of that url (first round trip to the server)
- find the HEAD revision of the repository (second round trip to the server)
- load the cache from disk for the UUID
- compare the HEAD revision with the last in the cache
- fetch missing revisions from the server (third round trip to the cache).
So all in all, you get 3 (three)!!! round trips to the server which
takes longer than just showing the last 100 revisions of e.g. TSVN. You
can assume about a second for each round trip.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Mar 30 19:13:23 2005