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.
> 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
Also, even though the children can nest infinitely, for the purposes
of this cache I think we just need the top-level children.
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 14:58:29 CET