On Fri, Aug 3, 2012 at 3:25 PM, Julian Foad <julianf...@btopenworld.com> wrote:
> It's time to lose the temporary '--symmetric' option and make it the default
> mode in 'svn'.
Sounds good. Just a couple of questions.
> * Make the '--reintegrate' option mean the user believes a
> reintegrate-style merge is needed, so check that the
> previous merge is as expected (that it, in the opposite direction) and
> bail out if not.
Why do you want to do this? Just to educate the user that they do not
need reintegrate? It does not seem like it would be necessary. What
happens today if the user does this? I guess if --reintegrate does
the wrong thing today then this makes sense. But if it basically
still gives a valid result why bother to make a behavior change in
what is a deprecated option anyway?
> * A merge specifying '-r X:Y' will not change. This requests a cherry-pick
> merge, using merge tracking to avoid
> re-merging any revs in the range that are already merged. Currently, if 'X'
> is 1 or a low enough number such that
> there are no unmerged revisions before 'X', then Subversion performs exactly
> the same kind of merge as when 'X'
> is not specified, which we call a 'sync' merge. I believe we could make a
> later enhancement to automatically use
> 'reintegrate' mode if that would be the correct thing to do for merging the
> requested range.
My question here is at the JavaHL API level.
Today, the API that we call to do a sync-style merge is the same as
the one we call to merge revision ranges. Specifically, here is the
signature:
/**
* Merge set of revisions into a new local path.
* @param path path or url
* @param pegRevision revision to interpret path
* @param revisions revisions to merge
* @param localPath target local path
* @param force overwrite local changes
* @param depth how deep to traverse into subdirectories
* @param ignoreAncestry ignore if files are not related
* @param dryRun do not change anything
* @param recordOnly record mergeinfo but do not run merge
* @throws ClientException
*/
void merge(String path, Revision pegRevision, List<RevisionRange> revisions,
String localPath, boolean force, Depth depth,
boolean ignoreAncestry, boolean dryRun, boolean recordOnly)
throws ClientException;
When we want to a sync-style merge we pass a single RevisionRange
object in the List with values of 0 for the Start and End revision. I
see the following note:
> [7] GUIs and other clients can switch to the new svn_client API when
> they are ready to do so; here I'm just talking about our 'svn' client.
Do you plan on adding a new mergeSync API to JavaHL or just have the
JavaHL C++ code call the new API when the RevisionRange is passed as I
noted above? I would be fine with the latter as I do not think it
introduces any unexpected new behaviors. There is already a specific
mergeReintegrate JavaHL API.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
