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

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

From: Noorul Islam K M <noorul_at_collab.net>
Date: Fri, 01 Jul 2011 15:58:05 +0530

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

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.

I would like to give summary of discussions that happened regarding this

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:


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.


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.


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


> 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.


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

This is an archived mail posted to the Subversion Dev mailing list.