On Tue, Feb 15, 2011 at 9:48 AM, Hyrum K Wright <hy...@hyrumwright.org>wrote:
> On Mon, Feb 14, 2011 at 11:33 AM, Noorul Islam K M <noo...@collab.net> > wrote: > > > > See below in line more information about the patches. > > > > Noorul Islam K M <noo...@collab.net> writes: > ... > >> 3. Issue 3690 > >> > >> http://svn.haxx.se/dev/archive-2011-01/0414.shtml > >> > >> This is actually an enhancement and there were two approaches. One > >> that I initially submitted and another one suggested by Hyrum. This > >> thread has three to four patches which are pending review. May be it > >> is not getting reviewed because it is not yet finalized how are are > >> we going to proceed. > >> > > > > Above thread contains patches for issue 3690 which adds an option > > "--ignore-properties" to log command so that user can ignore revisions > > which has only property changes. > > I've said multiple times (both in regards to this, as well as the > ignore-mergeinfo-log branch) that I'd appreciate some discussion > surrounding the applicability of these features before committing > them. Part of me sees the use, as they solve a real usability problem > in my own life, but another part of me wonders if these are specific > fixes for which other (non-core) solutions would be appropriate. > > Maybe I should spearhead that discussion, since I'm the guy who wants > it so badly, but unfortunately my supply of tuits has been quite low > lately. I'm just not in any rush to get this work on trunk, as if we > do add this functionality, I'd like to do it for as many subcommands > as is reasonable, all in the same release. And that ain't happening > before 1.7 (imho). > > -Hyrum > My 0.02c - there was a question raised on the users@ list, regarding the ability to see the changes that *only* relate to properties. The use case was seeing the log for svn:externals changes on a directory. I guess this is the opposite of the above request: one where we can exclude all property changes, the other where we want nothing but property changes. Cheers, Daniel B.