On 5/9/06, Andreas Hasenack <ahasenack@terra.com.br> wrote:
> [resending after being subscribed, seems the moderators have got their
> hands full]
>
> On Mon, May 08, 2006 at 07:39:54PM -0000, dionisos@tigris.org wrote:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=2543
> >
> > ------- Additional comments from dionisos@tigris.org Mon May 8 12:39:54 -0700 2006 -------
> > Although the issue tracker is not for discussion (you're welcome to discuss this
> > further on dev@), I'll respond here for once.
> >
> > The result from a patch which includes the add is *not* the correct result,
> > since the fact that the add stems from a rename is lost (i.e. the fact that the
> > original add was *with history*).
>
> 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.
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...
bye,
Erik
(alias dionisos)
Received on Tue May 9 19:41:59 2006