On Dec 10, 2007 11:24 AM, Stefan Küng <email@example.com> wrote:
> David Glasser wrote:
> > On Dec 6, 2007 11:40 AM, Stefan Küng <firstname.lastname@example.org> wrote:
> >> Hi,
> >> I don't know when this happened, but with a client built from trunk 'svn
> >> diff' does not include added files anymore in the resulting diff:
> >> cd wc
> >> svn revert -R .
> >> svn mv somefile somefile1
> >> svn diff > diff.txt
> >> the resulting diff contains only the removed file (an entry with "Index:
> >> ..." for 'somefile' with all lines removed, but no entry with "Index:
> >> ..." for 'somefile1' with all lines added.
> >> client build from r28185 of the svn trunk, but I haven't seen any
> >> changes to the diff part since then, so I assume it works the same with
> >> HEAD.
> > Is this a regression? It looks to me like both trunk and 1.4.x show
> > diffs of copied files against the copy base (not the empty file), and
> > show no output if the file is not changed.
> Ops, you're absolutely right!
> That means the "apply patch" feature in TortoiseMerge has been broken
> for a long time...
> But I wonder: the 'svn diff > patchfile' is used to create patchfiles
> and send them to others. But the created patchfile has *no* indication
> of the renamed file: it only shows the old file with all lines removed.
> Which means: if I would rename a file, create a patch and sent this
> patch to someone else, that person would end up with a removed file and
> a missing new file.
> I would expect the diff to produce the diff for the 'added' file too.
> If I remove the file, then add it again with a new name (*not* a
> rename), then the diff contains the added file as expected.
Indeed, "svn diff" doesn't give the full information necessary to
apply a patch. See Charles Acknin's work this summer...
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Dec 10 21:02:45 2007