I am revisiting this issue after 6 months. I stopped working on this because everyone was busy working towards 1.7 release. The then thread was getting little attention.
Link to the issue is http://subversion.tigris.org/issues/show_bug.cgi?id=3690 and following is the initial comment in the issue tracker. Pasting it here. <snip> Add an option to ignore files with only property changes and no content changes. e.g. svn log --ignore-properties Motivation: many users are not interested in reviewing changes to property changes and only care about content changes. </snip> I would like to give summary of discussions that happened regarding this issue. In issue desc2 Hyrum said the following. A subset of this problem (namely, ignoring changes to svn:mergeinfo) is being addressed on the ignore-mergeinfo branch: http://svn.apache.org/repos/asf/subversion/branches/ignore-mergeinfo But I was in the opinion that --ignore-properties requirement is bit different from --ignore-merge-info. So I submitted a patch against trunk adding new option --ignore-properties to log sub command. This patch implements new functionality on ra_local layer alone. http://mail-archives.apache.org/mod_mbox/subversion-dev/201101.mbox/%3c87aaihf203.fsf...@sajida.noorul.com%3E Hyrum replied to the patch asking me why I was not working against ignore-mergeinfo branch. Then I started looking at the code in ignore-mergeinfo branch and tried to use the ignored_prop_mods parameter to filter out the properties. I started submitting series of patches against the branch. But later I was stuck because we are allowed to define any props we want in the 'svn:' namespace, and ignored_prop_mods takes list of pre-defined keywords. Also I agree with what Hyrum said: > The "skip any and all prop mods" functionality is actually easier than > the "skip selective prop mods" functionality because of the way we > store history in the FS and walk history in the repos. Long story > short: knowing that there was a prop mod is almost a free operation > (in the context of other stuff); finding out *what* was modified (and > therefore what should be filtered) takes a bit more work. The entire thread can be read here. http://mail-archives.apache.org/mod_mbox/subversion-dev/201101.mbox/%3c87aaihf203.fsf...@sajida.noorul.com%3E I believe that my patch attached in the above thread is very straight forward and simple. It will be great if someone could take a look at the patch and give comments. Later when I pinged the list on a separate thread about the patch, Daniel Becroft said the following here http://mail-archives.apache.org/mod_mbox/subversion-dev/201102.mbox/%3CAANLkTi=6hmlf06na81swpred-f1jursjjm+xxawfk...@mail.gmail.com%3E > 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. I think we can eventually add another option to log command --properties-only to list revisions that have properties changes alone. Finally Stefan Sperling said the following here. http://mail-archives.apache.org/mod_mbox/subversion-dev/201102.mbox/%3c20110215152716.gp1...@jack.stsp.name%3E > I haven't been following this closely. But as Hyrum points out, > it seems that more design work is needed before much coding can be done. > > Branch or not, you'll need to find a full committer willing to help > with the design and review the implementation. > > The problem with that is that most developers are currently focused > on working towards the 1.7 release. There is little room at the > moment for designing new features that aren't planned to appear in 1.7. > > So maybe we can postpone work on this feature for later? > > In the meantime, there are quite a number of issues with milestones > 1.7.0 and 1.7-consider. Those are likely to catch more attention at > the moment, since everyone is focused on getting the release done. I agreed with Stefan and stopped working on this. Now since we are about to branch for 1.7, I hope this is the right time to work on this again. With respect to design issue, it will be great if the patch I submitted initially is reviewed and give comments about the approach. I think it is very straight forward and simple. I can re-work my patch against latest trunk as soon as we branch 1.7. Thanks and Regards Noorul
