[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Improvements to 'svn mergeinfo' subcommand for 1.7

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 14 Aug 2009 11:16:21 -0400

On Fri, Aug 14, 2009 at 11:00 AM, Mark Phippard<markphip_at_gmail.com> wrote:
> On Fri, Aug 14, 2009 at 10:54 AM, Paul Burba<ptburba_at_gmail.com> wrote:
>> I'd like to make two changes to the svn mergeinfo command for 1.7 to
>> address these drawbacks:
>> 1) Account for Non-Inheritable Revision Ranges
>> ----------------------------------------------
> +1 to this one.  I think it is a no-brainer that we should definitely just do.
>> 2) Optionally Consider Subtrees with Explicit Mergeinfo
>> -------------------------------------------------------
>> I'd like to add the --depth option to svn mergeinfo so these differing
>> subtrees are considered.  As above, revisions that are only partially
>> merged to the target would be marked with a '*':
> I am not sure about using --depth for this.  I think I would just use
> -R.  If you are going to use depth, then you need to make all of the
> different depth options have some kind of meaning, and I cannot see
> that being useful for this.  You pretty much either want to just base
> it on the target, or on everything (fully recursive).

I agree that the use cases for svn mergeinfo --depth immediates |
files are probably quite limited, but was under the impression that -R
| -N have effectively been deprecated in favor of --depth?

> Are you proposing any changes in the format of the output?

Yes, but only the addition of the '*' marker after revisions.

> My
> assumption is no.  IOW, you are not going to try to report that a
> certain subtree needs revisions that the target does not.

Definitely not planning anything like that right now.


Received on 2009-08-14 17:16:47 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.