I've found an error with the zoom. The combo box in the toolbar is
added several times if you open several editors. I'll fix it.
On Fri, Jul 11, 2008 at 5:49 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> 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
> with EditorInput.
>
> 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
> * loop
> - 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/3240/2658781686_a7a50e4e57_o.png
>>> 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
>> properly.
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>>
>> ---------------------------------------------------------------------
>> 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.
> http://www.ribesoftware.com
> ribe_at_ribesoftware.com
>
> Contacto personal
> eMail: gimenete_at_gmail.com
> GTalk: gimenete_at_gmail.com
> msn: gimenete_at_hotmail.com
> página web: http://gimenete.net
> teléfono móvil: +34 625 24 64 81
>
--
Alberto Gimeno Brieba
Presidente y fundador de
Ribe Software S.L.
http://www.ribesoftware.com
ribe_at_ribesoftware.com
Contacto personal
eMail: gimenete_at_gmail.com
GTalk: gimenete_at_gmail.com
msn: gimenete_at_hotmail.com
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 18:19:53 CEST
