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

Re: Feature Request -- svn commit --unimportant

From: Ben Reser <ben_at_reser.org>
Date: Sun, 06 Oct 2013 18:54:18 -0700

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.
Received on 2013-10-07 03:54:53 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.