> -----Original Message-----
> From: Daniel Rall [mailto:dlr@collab.net]
> Sent: Thursday, April 26, 2007 5:31 PM
> To: Kamesh Jayachandran
> Cc: dev@subversion.tigris.org
> Subject: Re: [PATCH] Implicit detection of merge source URL
> and merge revision range
>
> 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!
> >
> > > >>- " 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.
>
> We need to:
>
> a) Finish discussing this soon.
>
> b) Write some tests for this, either way.
>
> I'll start on (b).
In r24811 I added at test for 'svn merge WCPATH -r N:M' to the existing
merge test mergeinfo_inheritance_and_discontinuous_ranges and set it as
XFail.
Dan, I saw you removed this section,
-* Make revision and source URL parameters to the 'svn merge -cN URL'
- command to be optional (via use of merge info and copy history).
- Support this via the API itself (in addition to the command-line
- client). (kamesh/dlr)
-
- * Default merge source (a URL) to any single source in merge info
- already present on the target of the merge. If there are multiple
- previous merge sources, a specific source must be specified.
-
- * Default revision range (e.g. for -r/-c) to "all unmerged
revisions",
- "oldest revision at merge source's path" thru HEAD.
from notes/merge-tracking.txt in r24803. Don't we want to keep the
second bullet in there for now?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 27 05:17:24 2007