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

Re: Enabling symmetric merge, and UI details

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 3 Aug 2012 21:54:11 +0100 (BST)

Mark Phippard wrote:
> On Fri, Aug 3, 2012 at 3:25 PM, Julian Foad 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?

I was thinking the main alternative would be to silently ignore it, and that seems unnecessarily misleading.  But I guess you are thinking the main alternative is to keep it doing exactly what it does today.  I don't have a strong objection to that, but I feel we can do a better service for the user by reporting if the user seems to have made a mistake, because it seems to me that a significant cause of merge problems in the real world is users making a mistake (forgetting which WC they're in, for example).

>  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?

Today, if the user gives the --reintegrate option when a non-reintegrate merge is the appropriate one based on past merges, Subversion goes through the motions of a reintegrate merge and produces the wrong result.  (Wrong in the sense that it doesn't properly merge the sets of unique changes from the two branches, not that it doesn't do exactly what we taught it to do.)

>>    * 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.

I would prefer to add a new API to JavaHL, as the current merge API is already way too overloaded with variations of behaviour in my opinion.

- Julian
Received on 2012-08-03 22:54:47 CEST

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