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

Re: [PATCH] 'svn st --ignore-prop' (was Re: Proposal: --no-props switch for 'log', 'st' and 'diff')

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Thu, 04 Sep 2008 09:43:18 -0500

Julian Foad wrote:
> On Thu, 2008-09-04 at 08:55 -0500, Hyrum K. Wright wrote:
>> Hyrum K. Wright wrote:
>>> I'm currently investigating a generic '--ignore-prop' switch, initially for 'svn
>>> st'. It is being written in such a way that we could easily alias
>>> '--ignore-mergeinfo' or '--forget-merges' or
>>> '--dont-get-in-my-way-i'm-trying-to-do-real-work' to mean '--ignore-prop
>>> svn:mergeinfo'. I hope to have a proof-of-concept patch done in a few days.
>> As promised, here's a patch which implements the above. It completely
>> implements the functionality which it claims to, but there is still future work
>> to be done to flesh out the feature. This does not add a '--ignore-mergeinfo'
>> alias as discussed above, but adding such would be trivial.
>> I'd appreciate any feedback, but if there aren't serious objections, I'll commit
>> the patch in the next day or two.
>> [[[
>> Add support for ignoring arbitrary property modifications in 'svn st'.
>> This currently only works locally, not with 'svn st -u'.
> We should always be cautious about complexifying libsvn_wc. Can I ask
> whether and why it is beneficial to add this complexity into libsvn_wc
> rather than filtering at the presentation layer?

The reason here is that libsvn_wc isn't returning the knowledge of which props
were changed to the client, just whether or not *any* properties were modified.

After talking with Julian on IRC, we agreed that the current approach may be a
bit invasive for libsvn_wc. I'm going to take a look at whether or not we can
leverage existing libsvn_wc APIs to move the core functionality into libsvn_client.


Received on 2008-09-04 16:43:43 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.