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

Re: Simple Question, go back revision

From: Vincent Lefevre <vincent+svn_at_vinc17.org>
Date: 2006-02-25 01:49:30 CET

On 2006-02-24 08:15:10 -0500, Andy Levy wrote:
> On 2/24/06, Vincent Lefevre <vincent+svn@vinc17.org> wrote:
> > Yes, this is what I meant. In such a way one won't see rev 16 in the
> > log of the file in HEAD and it will be invisible to "svn blame", if
> > this is what one wants...
>
> Then I think you're talking about obliterating that revision entirely,
> which is something that cannot be done today without dumping, editing,
> and reloading.

No, I'm not talking about this. I mean something like this:

--- r15 --- r16 --- deleted (r17)
     `--- r18

Since r16 is in a different branch, its effect won't be seen by
a "svn blame" on the file from the head.

> > > IMHO, better to use the reverse merge than a delete/copy.
> >
> > Why better?
>
> It keeps (in my view, anyway) the history of everything that happened
> to the file completely intact. So that if I need to go back in a few
> weeks because I forgot *why* something was a bad idea, the whole thing
> will be logged.

However, if you do a "svn blame" on the file, you'll see lines coming
from the reverse merge instead of the really origine of these lines.
Also, not seeing the log of r16 with a "svn log" on the file is also
a plus for me. The log of r16 can still be seen in the logs on the
directory.

-- 
Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 25 01:50:53 2006

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

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