You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gabriela Gibson <ga...@gmail.com> on 2013/10/05 17:47:58 UTC
Feature Request -- svn commit --unimportant
Hi,
The following conversation took place on the svn-dev IRC yesterday
evening, with Eitan Adler:
[22:34] <Eitan> feature request: "svn commit --unimportant" which does
not destroy "svn blame" unless you write "svn blame --all"
[22:44] <cinnamon> Eitan: what were you trying to do that made you think
of this?
[22:45] <Eitan> cinnamon: fix up whitespace errors
[22:45] <Eitan> cinnamon: the idea is similar to wikipedia's "trivial edit"
[22:46] <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
[22:46] <cinnamon> nod, that would defeat the purpose of blame somewhat
[22:46] <lgo> you can of course use the ignore white space option for blame
[22:47] <Eitan> lgo: in some cases it isn't just whitespace
[22:47] <Eitan> for example, in our documentation we use "&os;" instead
of "FreeBSD"
[22:47] <Eitan> and I'd love to be able to change all the latter to the
former
[22:47] <Eitan> etc. etc. etc.
[22:48] <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.
Gabriela
Re: Feature Request -- svn commit --unimportant
Posted by Lorenz <lo...@yahoo.com>.
Gabriela Gibson wrote:
>I can see Eitan's point -- if we went ahead and changed all the obsolete
><tt> tags on the Subversion website, it would remove a lot of useful
>blame info.
>
>Is a two stage operation possible?
>
>say, you type:
>
>'svn commit --blame-revert ...'
>
>Part one would be a regular commit, part two would be a second commit that
>restores all the original authors that the first commit modified; so one
>commit would produce two consecutive revisions.
to my understanding there is no explicit blame info stored in the
repo. Instead, when the client request the blame, the server walks
back through the revisions of the file and collects the required info.
So there is nothing about blame that could be restored.
And regarding the idea of an svn:exclude-this-revisions-from-blame
property:
I would strongly recommend a warning to be issued by the client if
there were such a property set on the file (and relevant for the
requested blame range)
On the other hand, a --exlude-revision(s) command line option could be
useful.
It would provide the functionality without the danger the user might
not recognize that revisions had been excluded during blame info
computation.
--
Lorenz
Re: Feature Request -- svn commit --unimportant
Posted by Ben Reser <be...@reser.org>.
On 10/6/13 5:29 PM, Gabriela Gibson wrote:
> I can see Eitan's point -- if we went ahead and changed all the obsolete
> <tt> tags on the Subversion website, it would remove a lot of useful
> blame info.
No it doesn't. All the information is still there. It's harder to step back
through revisions with the cmdline client because the display format is not
suited very well for that. But you can still do it, just pass a revision one
before the revision the line you're looking at changed in. A GUI could just as
easily support a feature where you could walk through changes interactively to
find where what you were looking for really happened (we could even make that
much easier for the GUI to support than it is now).
> Is a two stage operation possible?
>
> say, you type:
>
> 'svn commit --blame-revert ...'
>
> Part one would be a regular commit, part two would be a second commit that
> restores all the original authors that the first commit modified; so one
> commit would produce two consecutive revisions.
>
> To be (relatively) safe, this could be a repository admin action only.
I honestly can't really fathom how you'd implement 'blame-revert'. Either a
commit revision modified a line in the file or it didn't.
Personally I'd much rather walk through changes and know that I've found what I
wanted rather than hope that someone didn't tag something as "unimportant" that
really was important for what I'm looking for. The idea that you can decide
what a user far in the future is going to find important at commit time when
running blame seems like a rather strange idea to me.
Re: Feature Request -- svn commit --unimportant
Posted by Gabriela Gibson <ga...@gmail.com>.
I can see Eitan's point -- if we went ahead and changed all the obsolete
<tt> tags on the Subversion website, it would remove a lot of useful
blame info.
Is a two stage operation possible?
say, you type:
'svn commit --blame-revert ...'
Part one would be a regular commit, part two would be a second commit that
restores all the original authors that the first commit modified; so one
commit would produce two consecutive revisions.
To be (relatively) safe, this could be a repository admin action only.
Gabriela
On Sun, Oct 6, 2013 at 8:45 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> > Sent: zaterdag 5 oktober 2013 17:48
> > To: Subversion Development; lists@eitanadler.com
> > Subject: Feature Request -- svn commit --unimportant
> >
> > Hi,
> >
> > The following conversation took place on the svn-dev IRC yesterday
> > evening, with Eitan Adler:
> >
> > [22:34] <Eitan> feature request: "svn commit --unimportant" which does
> > not destroy "svn blame" unless you write "svn blame --all"
> > [22:44] <cinnamon> Eitan: what were you trying to do that made you think
> > of this?
> > [22:45] <Eitan> cinnamon: fix up whitespace errors
> > [22:45] <Eitan> cinnamon: the idea is similar to wikipedia's "trivial
> edit"
> > [22:46] <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
> > [22:46] <cinnamon> nod, that would defeat the purpose of blame somewhat
> > [22:46] <lgo> you can of course use the ignore white space option for
> blame
> > [22:47] <Eitan> lgo: in some cases it isn't just whitespace
> > [22:47] <Eitan> for example, in our documentation we use "&os;" instead
> > of "FreeBSD"
> > [22:47] <Eitan> and I'd love to be able to change all the latter to the
> > former
> > [22:47] <Eitan> etc. etc. etc.
> > [22:48] <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 assume you do know about the -x argument to blame where you can ask blame
> to ignore whitespace only changes?
> (E.g. add "-x -b", see 'svn help blame')
>
>
> In theory something like this could be implemented by adding some revision
> property to specify which commits to ignore. But it might be hard to keep
> things working if there are revisions where this property is supplied, but
> major changes are committed. In that case it would be very hard to show old
> revisions for some lines.
>
> Bert
> >
> > Gabriela
>
>
RE: Feature Request -- svn commit --unimportant
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: zaterdag 5 oktober 2013 17:48
> To: Subversion Development; lists@eitanadler.com
> Subject: Feature Request -- svn commit --unimportant
>
> Hi,
>
> The following conversation took place on the svn-dev IRC yesterday
> evening, with Eitan Adler:
>
> [22:34] <Eitan> feature request: "svn commit --unimportant" which does
> not destroy "svn blame" unless you write "svn blame --all"
> [22:44] <cinnamon> Eitan: what were you trying to do that made you think
> of this?
> [22:45] <Eitan> cinnamon: fix up whitespace errors
> [22:45] <Eitan> cinnamon: the idea is similar to wikipedia's "trivial
edit"
> [22:46] <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
> [22:46] <cinnamon> nod, that would defeat the purpose of blame somewhat
> [22:46] <lgo> you can of course use the ignore white space option for
blame
> [22:47] <Eitan> lgo: in some cases it isn't just whitespace
> [22:47] <Eitan> for example, in our documentation we use "&os;" instead
> of "FreeBSD"
> [22:47] <Eitan> and I'd love to be able to change all the latter to the
> former
> [22:47] <Eitan> etc. etc. etc.
> [22:48] <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 assume you do know about the -x argument to blame where you can ask blame
to ignore whitespace only changes?
(E.g. add "-x -b", see 'svn help blame')
In theory something like this could be implemented by adding some revision
property to specify which commits to ignore. But it might be hard to keep
things working if there are revisions where this property is supplied, but
major changes are committed. In that case it would be very hard to show old
revisions for some lines.
Bert
>
> Gabriela
Re: Feature Request -- svn commit --unimportant
Posted by Branko Čibej <br...@wandisco.com>.
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@wandisco.com
Re: Feature Request -- svn commit --unimportant
Posted by Julian Foad <ju...@btopenworld.com>.
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.
- Julian