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

Re: [Issue 2543] Inconsistent svn diff after rename

From: Andreas Hasenack <ahasenack_at_terra.com.br>
Date: 2006-05-09 19:42:25 CEST

On Tue, May 09, 2006 at 07:29:45PM +0200, Erik Huelsmann wrote:
> >Well, the current behaviour is certainly not correct, as a big part is
> >missing from the diff. In fact, data will be lost if the diff is
> >applied because the add operation is not there, only the delete one.
> >
> >After commit, of course, the diff is complete again, showing both delete
> >and add operations. It's unfortunate that diff doesn't have a rename
> >mode.
> But with the loss of the rename, a lot of data disappears too: the
> entire history of the file has suddenly disappeared. That's why I'm
> arguing that there is no right way to do this with diff+patch.

What I don't understand is that diff *never* had history. We are talking
about a text file representing differences. If this is such a big
issue then every single output of "svn diff" is wrong since day one.

> Also, imagine we had merge tracking right now, this would loose all
> merge tracking history. Having the diff of the added file included in
> the total diff would create the illusion of correctness, whereas all
> history including merge tracking has been lost.
> You simply can't move tree structure changes from one working copy to
> another with diff+patch...

I think we are not understanding each other. What I would like to have
is that svn diff right after svn mv should show exactly what it shows
after the commit is made. Currently it shows something different.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 9 19:48:06 2006

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