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







Reply via email to