Re: Feature Request -- svn commit --unimportant

On 06.10.2013 22:12, Julian Foad wrote:
> Gabriela Gibson wrote:
>
>> The following conversation took place on the svn-dev IRC yesterday
>> evening, with Eitan Adler:
>>
>> <Eitan> feature request: "svn commit --unimportant" which does
>> not destroy "svn blame" unless you write "svn blame --all"
>> <cinnamon> Eitan: what were you trying to do that made you think
>> of this?
>> <Eitan> cinnamon: fix up whitespace errors
>> <Eitan> cinnamon: the idea is similar to wikipedia's "trivial edit"
>> <Eitan> cinnamon: I'd love to go en mass through our code and
>> fix up internal whitespace errors but that would destroy "svn blame"
>> of who wrote what
>> <cinnamon> nod, that would defeat the purpose of blame somewhat
>> <lgo> you can of course use the ignore white space option for blame
>> <Eitan> lgo: in some cases it isn't just whitespace
>> <Eitan> for example, in our documentation we use
>> "&os;" instead of "FreeBSD"
>> <Eitan> and I'd love to be able to change all the latter to
>> the former
>> <Eitan> etc. etc. etc.
>> <Eitan> cinnamon: that is why I propose "blame" and
>> "blame --include-everything/"
>>
>> I think this would be a very useful addition for many users and so
>> that it does not get lost in the IRC chat, I thought I post it here
>> for discussion.
> I would like to suggest a different approach to this kind of task.
>
> The 'log' command was recently given a 'search' option by Stefan Sperling. In v1.8, 'svn log --search=foo' displays only revisions where the log message contains 'foo' or the author contains 'foo' or the list of changed paths contains 'foo' or the date contains 'foo'.
>
> A similar option to 'blame' would make sense. The use case is that you want the blame to ignore all the revisions where the change was 'whitespace only' or 'cosmetic' or 'comments only' or 'the change that user X made in revision Y' or some such condition. I think it makes sense to use exactly the same mechanism that allows us to specify which revisions 'log' should show, to control which revisions 'blame' should show.
>
> Of course, as well as allowing the 'search' option to be used in
> 'blame', we might also want to extend its capabilities, for example to
> have a negative form (revisions that do not match 'cosmetic'), or to be
> able to search for a rev-prop (revisions that do not contain a rev-prop
> named 'trivial-change') etc.
>
> For example, if you wanted to tag a commit as being trivial, you could put the text '[trivial]' in the log message, and then you could use "svn blame --search-not='[trivial]'" to only show non-trivial revisions.
>
> I think that sharing and extending an existing capability like 'search' makes a lot more sense than adding a specific switch to tag commits for one purpose (how would it tag them? with a revision property?) and another specific switch to ignore the specifically tagged commits.

I agree. Filtering should be a decision made by whoever invokes "blame",
not by the committer. The author of a commit shouldn't presume to know
what someone wants to know about his commit, or even what kind of
repository history analysis tools may be available in the future.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com