Well. I will think in a better way to retrieve and store the merge
information. By the moment I have committed some changes. Now the
merge information is shown in the revision graph. Merges are shown
with red arrows. Altought this adds more noise to the graph. But it's
the same problem we talked about: we'll have to implement filter
capabilities and maybe make changes in the layout algorithm.
As I said in the previous post the code also works if you change the
flag "includeMergedRevisions" to "false". So the merge information can
be disabled easily.
On Thu, Aug 28, 2008 at 12:32 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Aug 27, 2008 at 4:58 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Wed, Aug 27, 2008 at 1:34 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
>>
>>> I've committed a little change. Now the merge information is stored,
>>> but not shown in the graph yet. I store just the first nesting level.
>>> I'm using a "level" integer to know in which nesting level I am, and I
>>> ignore any log message deeper than level=1
>>>
>>> The implementation works with any value of "includeMergedRevisions".
>>> If "false" it simply won't know anything about merge information.
>>>
>>> I'm going to try to include the information in the graph output.
>>
>> On Subversion's own repository, this command essentially never ends:
>>
>> svn log -g -rHEAD:0
>>
>> Until the API gives us more control, I wonder if we could do things
>> differently to get a performance compromise? For example, maybe we
>> could just build the cache we do now, and provide a context option on
>> a revision node to get the mergeinfo "on demand" for just that
>> revision? This could update the cache for next time.
>>
>> We could also maybe do it on demand as the graph is built, but that
>> would make performance really inconsistent.
>>
>> I think we need to figure out some kind of way to defer getting the
>> information. Ideally the cache can still be updated when we do get it
>> though.
>
> Just to follow up. I have a local copy of the SVN repository I test
> with. Here are some timings:
>
> $ time svn log -rHEAD:0
> file:///Users/mphippard/repositories/svn-mirror > /dev/null
>
> real 1m27.066s
> user 0m3.582s
> sys 0m6.431s
>
> $ time svn log -g -rHEAD:0
> file:///Users/mphippard/repositories/svn-mirror > /dev/null
>
> real 20m10.677s
> user 11m5.939s
> sys 3m12.391s
>
> It used to take about 10 minutes for the revision graph cache to
> build. So the above 1+ minute command took roughly 10 times longer.
> If the ratio holds, and it might not, the second command would have
> taken over 3 hours to finish.
>
> --
> 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
---------------------------------------------------------------------
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-28 18:36:54 CEST