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
