[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] Revision graph GSoC application

From: Alberto Gimeno <gimenete_at_gmail.com>
Date: Fri, 28 Mar 2008 15:12:02 +0100

Thanks. I'll take a look to the ISVNLogMessage class.

On Fri, Mar 28, 2008 at 2:58 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Fri, Mar 28, 2008 at 9:50 AM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> > I've published my application for this task. I would like to read your
> > comments about it.
>
> Great! Thanks for applying and welcome to the project.
>
>
> > In my application I haven't talked about merges because I thought
> > Subversion doesn't save that information. But I see in subversion 1.5
> > this will be supported. Supporting merges won't be a big effort in my
> > proposal. But I'm taking a look at the JavaHL library in subversion
> > 1.5 and as far as I see there is no way to get information about
> > merges. The org.tigris.subversion.javahl.ChangePath class doesn't
> > holds any information about merges.
> >
> > http://svn.collab.net/viewvc/svn/branches/1.5.x/subversion/bindings/javahl/src/org/tigris/subversion/javahl/ChangePath.java?revision=29081&view=markup
> >
> > Am I wrong?
>
> Sort of. The log API has an includeMergedRevisions boolean. These
> wind up appearing in an array on the ISVNLogMessage class. There is a
> getChildren method that gives you the merged revisions. Each of these
> can also contain merged revisions.
>
> A problem is that if you run the log API on the repository root and
> for all revisions, I do not think this feature will work properly. It
> might also kill the server. This is what I suggest:
>
> When you are processing log entries, you will see property changes
> whenever a merge has occurred. You would need to figure out if the
> svn:mergeinfo property changed, and then run svn log on just that
> revision using the includeMergedRevisions boolean. This should give
> an accurate reading on what was merged in that revision. You could
> actually probably just run this API whenever you see a prop change and
> if that revision was not a merge, you just will not get any children
> back.
>
> Also, even though the children can nest infinitely, for the purposes
> of this cache I think we just need the top-level children.
>
> --
> 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-03-28 15:12:34 CET

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.