On Thu, 26 Apr 2007, Paul Burba wrote:
> > -----Original Message-----
> > From: Daniel Rall [mailto:email@example.com]
> > Sent: Thursday, April 26, 2007 5:31 PM
> > To: Kamesh Jayachandran
> > Cc: firstname.lastname@example.org
> > Subject: Re: [PATCH] Implicit detection of merge source URL
> > and merge revision range
> > On Tue, 24 Apr 2007, Daniel Rall wrote:
> > > 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
> 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
> - "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?
I was assuming this case worked since Kamesh's patch. Let's fix
whatever is wrong with it today instead.
its caller in merge.c should be handling this for us.
Received on Fri Apr 27 18:03:11 2007
- application/pgp-signature attachment: stored