Re: [Subclipse-dev] Revision graph and cache implementation

Hi!

I've fixed some things.

* Steve, I don't have any compile error.
* I think I've fixed the problem in MacOS X. Is this code ok?

String databaseName = f.getAbsolutePath();
if(File.pathSeparator.equals("\\"))
        databaseName = databaseName.replace('\\', '/');

The previous code was:

String databaseName = f.toUrl().toString().substring("file:/".length());

I tried to use f.toUrl().getPath() but it returns something like
"/C:/..." in Windows.

* Now author, date and message properties are shown in the graph.
* Now the progress bar is more accurate.

On Thu, Jul 31, 2008 at 9:49 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> Hi!
>
> Thank you very much for your comments. I've been too busy today to
> read them. I've been collaborating with Google here in Valencia
> (Spain). I talked about my experience at Summer of Code in general
> terms (timeline, payments, personal experience,...) and a little bit
> about the project. They will put the video on the official YouTube
> channel for Google Spain. So sorry it'll be in spanish :P
>
> Now the sky is dark and I'm tired. I'll reply you tomorrow, but thanks again :)
>
>
> On Thu, Jul 31, 2008 at 5:49 PM, <Stefan.Fuhrmann_at_etas.com> wrote:
>> "Alberto Gimeno" <gimenete_at_gmail.com> wrote on 07/23/2008 11:46:53 PM:
>>
>>> In your conclusions you say that the current implementation is not
>>> scalable ("Large histories will take days or even weeks to get
>>> cached"). I agree that this is because of the 'exploding' issue.
>>
>> Only as a side note: If I remember correctly, it took me ~30 hours
>> to fetch the log from apache.org. So, waiting days for the initial
>> cache fill is already the case for certain large, public repository
>> servers.
>>
>>> About the second approach you say that "is likely to deliver a worse
>>> "perceived" performance". I think you say that because this approach
>>> needs to do more things when the user wants to see a graph. With the
>>> current implementation all graphs are calculated at the same time.
>>> With the 'alternative' approach this is different: the user needs to
>>> wait more for each single graph.
>>
>> Agreed. My point with the "perceived" performance was as follows.
>> The best user experience you will get when things are fast enough
>> to be interactive. So, just loading the results should be considerably
>> faster than creating them. On the other hand, this advantage will
>> soon be offset by time necessary to update an "exploded" cache.
>>
>> Another side note. There is a way to combine both approaches.
>> It would calculate file ids, organize changes by file id but only
>> add a smallish, constant factor to the data size. I made some
>> sketches a few months ago and hope to get the design done by
>> the end of this year. If all goes well, it will provide interactive
>> performance while effectively evaluating all copy and merge graphs
>> at once.
>>
>>> However, what implementation do you think is the best? I think the
>>> second one. Because it is scalable.
>>
>> Agreed. With your "incremental graph update" proposal it should
>> scale well for all common uses.
>>
>>
>> Regards,
>> Stefan^2.
>>
>>
>> ---------------------------------------------------------------------
>> 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