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
Received on 2011-07-01 15:17:15 CEST