kfogel@collab.net wrote:
> Vincent Lefevre <vincent+svn@vinc17.org> writes:
>
>>On 2006-01-29 08:37:12 -0600, kfogel@collab.net wrote:
>>
>>>Folks, remember that reformatting old code will affect 'svn blame'
>>>information, and may make it harder to apply some currently
>>>outstanding patches. I'm not saying these issues should be decisive,
>>>just wanted to make sure everyone was aware of them before voting.
>>
>>Concerning 'svn blame', is this a good reason? I've noticed that
>>there is the same problem when the indentation must be changed
>>(e.g. because a 'if' is added...). IMHO, 'svn blame' should have
>>an option to be space-insensitive (possibly depending of where
>>the space occurs -- and this could depend on the svn:mime-type
>>value).
>
>
> I gave this some thought once, and came to the tentative conclusion
> that it's not trivial to implement.
>
> Actually, what I was thinking of was an 'svn:blame-transparent'
> revision property, that would cause that revision to be "transparent"
> to 'svn blame'. This way one could commit formatting fixes in their
> own revision, and have that revision not affect the blame information.
Yes, but ofcourse people are going to mix formmating fixes and code
changes in one revision in practice. Even in this project, where people
are very strict about that; consider the example of adding an if {}
block which requires reindenting. So I would be -1 on adding a
hack like svn:blame-transparent as a general feature.
> It was only when I started thinking about what this would actually
> mean, in concrete terms, that it started to get slippery... But if you
> (or someone) can figure out a way to do it, +1 :-).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 30 18:49:07 2006