On Thu, 26 Apr 2007, Paul Burba wrote:
> > -----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:
...
> > > 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?
I was assuming this case worked since Kamesh's patch. Let's fix
whatever is wrong with it today instead.
subversion/libsvn_client/log.c:svn_client__suggest_merge_sources() and
its caller in merge.c should be handling this for us.
- application/pgp-signature attachment: stored
Received on Fri Apr 27 18:03:11 2007