I had compile error too. getChangePaths instead of getChangedPaths.
Have not looked at this last commit.
Sent from my iPhone
On Aug 1, 2008, at 7:05 AM, "Alberto Gimeno" <gimenete_at_gmail.com> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-08-01 13:10:58 CEST