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

Re: svn commit: r33117 - in branches/ignore-mergeinfo/subversion: libsvn_client tests/cmdline

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 17 Sep 2008 10:31:38 -0400

On Wed, Sep 17, 2008 at 10:21 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> On Wed, 2008-09-17 at 08:26 -0500, Hyrum K. Wright wrote:
>> Daniel Shahaf wrote:
>> >> On the ignore-mergeinfo branch:
>> >> Teach the client diff APIs to honor the --ignore-mergeinfo flag. This
>> >> does not yet implement this for 'diff --summarize', so we error out
>> >> for that condition.
>> >
>> > Short(er) option for this? Maybe --no-g alias?
>> I'm really ambivalent about this; we can bikeshed about it later,
> +1!
>> I'd rather
>> just get the feature written so we can decide whether to merge it or not.
> Hyrum, I was talking to Paul about changing the mergeinfo handling to
> not add/change mergeinfo on nodes that didn't actually change. He thinks
> it's feasible. If we can do that, there will then be much less need for
> this option. That would be the best thing in the world, I think.
> However, even then, it would still be useful, especially on "svn diff"
> where the aim is to review changes or send a patch to someone, and on
> "svn log" of historical data; it's just that "svn status" should be nice
> and clean anyway, so we might want to omit the command-line option from
> "status". Note that "status" is where the biggest concern was over the
> negative consequences of hiding this information - the concern that
> people would look at "status" and then commit only the items shown as
> modified.
> This change to mergeinfo isn't certain, but I hope it works.


FYI: The thread this is being discussed is


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-17 16:31: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.