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

Splitting up the reintegrate merge API

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 27 Oct 2011 16:23:55 +0100

Given the the "reintegrate" merge is said to be an automatically
generated two-URL merge, it would be useful if Subversion client
programs had access to the component parts -- that is:

  * do the validity checks
  * determine which two source URLs (especially the "parent branch at
last sync'd rev" one)
  * run the standard two-URL merge function

That would enable the client to do things like print information after
the second step about what two-URL merge it is going to run, so that
the user can better understand what is happening.

(In the 'showing-merge-info' branch I currently have modified the
libsvn_client function merge_reintegrate_locked() to print a bit of
such info, but libraries are not allowed to print directly and sending
this info through some sort of callback mechanism would be entirely
the wrong way to go.)

Currently merge_reintegrate_locked() calls
merge_cousins_and_supplement_mergeinfo() to do the actual two-URL
merge. That function is a subroutine of the standard two-URL merge
function, and I'm not quite sure how it fits in but it appears to be
responsible for doing a two-URL merge in which one source is a direct
ancestor of the other, whereas the full two-URL merge as implemented
in merge_locked() can also do a diff between two URLs that have a
common ancestor, forming a Y-shaped ancestry graph. In such a case it
calls merge_cousins_and_supplement_mergeinfo() to do one branch of the
Y, and then calls do_merge() to do the other branch of the Y. I'm not
sure yet whether merge_cousins_and_supplement_mergeinfo() should
become public functionality and the reintegrate code should call it,
or whether the reintegrate code should call the full two-URL merge.

Thoughts?

- Julian
Received on 2011-10-27 17:24:30 CEST

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