>On Tue, 24 Apr 2007, Daniel Rall wrote:
>> On Tue, 24 Apr 2007, Kamesh Jayachandran wrote:
>...
>> > >>--- subversion/svn/main.c (revision 24527)
>> > >>+++ subversion/svn/main.c (working copy)
>> > >>@@ -513,7 +513,7 @@
>> > >> ("Apply the differences between two sources to a working copy
>> > >> path.\n"
>> > >> "usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]\n"
>> > >> " 2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]\n"
>> > >>- " 3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]\n"
>> > >>+ " 3. merge [-c M | -r N:M] [SOURCE[@REV]] [WCPATH]\n"
>> > >>
>> > >
>> > >I'd expect to this to be:
>> > >
>> > > merge [-c M | -r N:M] [SOURCE[@REV] [WCPATH]]
>> >
>> > No. It fails to cover the following case.
>> >
>> > merge [-c M | -r N:M] MY_WCPATH
>> >
>> > According to above syntax MY_WCPATH would be equated with SOURCE which
>> > is not correct.
>>
>> With this syntax, you can't differentiate between SOURCE and WCPATH,
>> since SOURCE can be a WC path (which corresponds to the merge source
>> URL). When SOURCE is itself a WC path, we've always assumed that the
>> target WC path for the merge is ".", which effectively means that the
>> WCPATH parameter can't be specified unless a SOURCE parameter is
>> provided.
>>
>> Can you describe why it makes sense to change this now? Thanks!
It is odd for me to think of the following usecase.
PARENT_DIR_OF_FEATURE_BRANCH$ svn merge feature-branch (I think this should merge feature-branch to its latest copy-source, not merging '.'(PARENT_DIR_OF_FEATURE_BRANCH) with feature-branch changes.
>>
>> > >>- " 3. In the third form, SOURCE can be a URL, or working copy
>> > >>item\n"
>> > >>- " in which case the corresponding URL is used. This URL in\n"
>> > >>+ " 3. In the third form, SOURCE should be a URL if given. \n"
>> > >>
>> > >
>> > >Since SOURCE can be a WCPATH, the above wording needs to be changed.
>> >
>> > I am referring SOURCE in the above context not in a generic sense. All I
>> > mean is SOURCE(If given) should be a absolute URI, If SOURCE is omitted,
>> > we will derive the SOURCE URL from from WCPATH target.
>> >
>> > <snip from my original log>
>> > This feature causes conflicts with one use case of existing feature.
>> > Currently revision based ranges can be of the form
>> > "3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]\n"
>> > Making SOURCE and REV_RANGE optional in the above command results in the
>> > following type of invocation.
>> > "merge WC_SOURCE[@REV] [WCPATH]\n", this causes the ambiguity with
>> > "2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]\n".
>> >
>> > So to fix this we mandate SOURCE in 3rd style of merges to be a URL if
>> > given.
>> > </snip>
>> > I think I should use 'sourceURL' instead of 'SOURCE' to make things less
>> > ambiguous.
>>
>> This alters both the UI and the semantics of the command-line in an
>> incompatible fashion. You're suggesting that we make the assumption
>> that WCPATH is the merge source, in addition to its existing semantics
>> of being the WC target path.
I am not saying WCPATH is a merge source. I am saying in 3rd style of merges TARGETS[0] should be MERGE_SOURCE_URL to disambiguate with style 2.
With regards
Kamesh Jayachandran
Received on Fri Apr 27 16:42:21 2007