I have just committed the changes. It all seams to work, but I've made
several changes in a short time and I haven't already fixed the issue
It would be a good idea to have the log API to work with a callback.
What I do now is the following: (see ShowGraphBackgroundTask.execute()
* calculate the latest revision in the cache
* calculate the latest revision in the repository
- query next 100 log messages
- if the cache updater thread is alive, wait for it
- update the cache with those log messages (runs in a sepparate thread).
I don't know anything about the underlying API and protocol. For
example I don't know if every time I ask for an array of log messages
the API opens a new connection. In that case it would be better to use
callbacks. Or for example it would be better that the number of log
messages retrieved each time should be decided for the underlying
protocol / API.
This is like the InputStream.read(byte) method. It returns an
integer with the number of bytes read from the stream and copied into
the array. Depending on the underlying system it can read 256 bytes
each time, or 1024 bytes sometimes and 512 bytes others.
I don't know if I have explained myself correctly, my english is far
from being perfect, sorry :P
On Fri, Jul 11, 2008 at 5:06 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Fri, Jul 11, 2008 at 10:56 AM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
>> Thak you very much for your comments. I'll respond to you next week.
>> I've been too busy with my studies. I'm studying your comments. I'd
>> like to discuss especially your idea about putting a foreign key to
>> the parent directory. What I do now is the following: if I get a
>> "deleted /foo/bar" I insert a row per subfile or subdirectory marking
>> them as deleted in that revision, and as you say this not linear, this
>> has a 1:N behaviour. I'll write a more concise mail next week.
>> This week I have had time to do some improvements:
>> * Now the code is threaded (one thread queries the repository while
>> other thread updates the cache).
>> * Zoom in-out
>> * colours showing the type of change (delete: red, modify: blue,
>> add/copy: green).
>> * tooltips showing date, author and comment
>> some shots:
>> http://farm4.static.flickr.com/3062/2657955813_3a22ec4170_o.png (zoomed out)
>> The graph shown is the "plugin.xml" file from the subclipse core
>> plugin repository.
>> What I want to do now is:
>> * discuss the cache design
>> * put an option to hide the tags or show them in a different way
>> (maybe as an overlay icon)
>> * put an option to navigate to a certain branch (probably a combobox,
>> however I don't know how to do that yet)
>> * outlineview
>> * make it nicer :P
>> * make the background task cancellable. This should be not very
>> difficult now that I update the cache in several steps.
> It all sounds good! Commit it so we can play with it.
> You never commented about changing the log API to a callback. As I
> said, the underlying API supports it, we would have to expose it to
> svnClientAdapter. It seems like it could have positive performance
> implications as you could in theory have one thread receiving the log
> callbacks as Subversion receives them, and then perhaps posting those
> to some queue that another thread is processing to populate the cache.
> I'd think this would have to reduce the total time spent in the
> operation, but also assumed the threading can be made to work
> Mark Phippard
> To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Alberto Gimeno Brieba
Presidente y fundador de
Ribe Software S.L.
página web: http://gimenete.net
teléfono móvil: +34 625 24 64 81
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-07-11 17:50:08 CEST