On 12/08/2010 09:21 PM, Julian Foad wrote:
On Sat, 2010-12-04, Kamesh Jayachandran wrote:
I understand your patch fixes the following two cases.
1. svn di -cN explicitly_reinstated_file_with_mod_at_rN
Hi Kamesh and Prabhu.
What you're describing here sounds good - it sounds like a simpler and
more definite change than what I understood before - but I'm not sure
precisely what "explicitly_reinstated_file_with_mod_at_rN" means.
I mean the following,
[...]
Thanks, Kamesh - that clarifies it. So that's the case where a file is
deleted and then a pre-deletion revision of it is copied back to the
same path where it existed before.
In my experiments I find the same problem also exists when a file is
copied to a new path from a revision older than the value of HEAD at the
time of the copy. For example:
$ cd wc
$ echo "line1"> test.c
$ svn add test.c
A test.c
$ svn ci -m "" test.c
Adding test.c
Transmitting file data .
Committed revision 1.
$ svn mkdir ^/foo -m "An unrelated change"
Committed revision 2.
$ svn cp test.c new.c
A new.c
$ echo "line2">> new.c
$ svn ci -m "" new.c
Adding new.c
Transmitting file data .
Committed revision 3.
$ svn diff -c3 new.c
svn: Unable to find repository location for 'new.c' in revision 2
$ svn diff -c3
Index: new.c
===================================================================
--- new.c (revision 0)
+++ new.c (revision 3)
@@ -0,0 +1,2 @@
+line1
+line2
Please could you include a test for these cases in your patch? Then it
will be absolutely clear.
Prabhu already has one. Right now he is working on removing the
profileration of UI param diff-copy-from from all the layer in favour
of generic send_copyfrom_args.
That's great. It would be good to include the above test scenario as
well.
Thanks.
- Julian
Sure he would. Right now he is teaching the 'svn_wc_get_diff_editor6'
what he has taught for svn_client__get_diff_editor.
He will have tests for that too.
With regards
Kamesh Jayachandran