Issue #3690 - "svn log" with ignore property changes

[Noorul Islam K M <no...@collab.net>]

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+xXAWFkqcu@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.GP1958@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