[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Wed, 17 Sep 2008 09:40:34 -0500

Julian Foad 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.

Agreed. I would much rather see us not generate the noise to begin with than to
have to mask it later on. I won't proceed any farther on 'svn st -u' until this
discussion has reached some conclusion.

> This change to mergeinfo isn't certain, but I hope it works.

So do I!


Received on 2008-09-17 16:40:55 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.