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