>>> Since we have to wait around 30s for the log messages to show, this
>>> is a fairly critical problem. Otherwise, an excellent tool!
>>
>> Caching log messages would be very neat. Definitely doable, since
>> repository revisions is immutable.. Well, except that log messages
>> can be changed if you add a hook that allows it. We could happily
>> ignore that fact and tell users to turn off caching if they do that
>> and vice versa. Perhaps a radio button that allows two selections,
>> "enable log message/author editing" and "cache log messages"...
>
> Another option for the settings dialog???
Yes, but an important one ;-).
>> We'd probably need a unique identifier (GUID sort of) that identifies
>> each repository, so we can detect when a repo is changed on the
>> server (pulled away and replaced by another or what not)?
>
> Every repository already has an UID. TSVN uses that UID already to
> determine if a working copy paths belong to the same repository (for
> commits and for the URL history to show).
Great!
>> Or maybe just some silly workaround, like having the messages in
>> cache, but retrieving messages from HEAD and back to the latest
>> revision in the cache - including the latest revision in the cache.
>> Do a compare and say things are OK if that top entry from the cache
>> matches the first (oldest) of the entries just retrieved.
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
- No such revision as top-most-cached (cache invalid)
- 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
...We'll just reload every single message. Start with the newest
messages first, if it can be done, so that we have something to show
the user.
Reminds me, a "Refresh" button somewhere probably wouldn't hurt.
>> A log message cache would remove the need for the "Get all messages"
>> buttons too, thus simplifying the GUI.
Above "Refresh" button kinda moots this point of. The speedup still
applies though.
> 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.
We would need effective filtering mechanisms, but those are readily
available in great bounty.
> 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.
Cache it to disk to avoid any startup delay. Exactly like TSVNCache does.
Run-length encode the message strings in memory if need be, or just
let filesystem caching or memory-page aging algorithms take care of
what goes to disk and what stays in memory. I hear that Windows
excels at this stuff.
> - 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.
> - implement a special filter so if the user requests a log for just a
> file only the log messages for that files are shown
Yes.
That can be done infinitely more efficient than the current Subversion
algorithm, IMHO.
Which is basically the point of the whole idea.
Incidentally, if anyone has details on why Subversion is so slow when
loading log messages, that would be very interesting.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Mar 30 18:45:06 2005