On Wed, Oct 19, 2011 at 7:38 AM, Mark Phippard <markp...@gmail.com> wrote: > On Wed, Oct 19, 2011 at 12:00 AM, Hyrum K Wright > <hyrum.wri...@wandisco.com> wrote: > >>> * r1181609: Fixes a major regression for our api-users that perform a 'svn >>> status -U' . >> >> This was merged to 1.7.x in r1185955. > > FWIW, in Subclipse we are seeing another one of these, When there is > an incoming delete from the repository the status=none as it is for an > Unmodified file. I believe it used to say the item was deleted. I > just got the details last night so do not have a test for it yet. I > think we already have a JavaHL test that sets up this scenario but we > might not be checking that part of the structure in the test. I > recall the main goal of that test was to verify that we identified the > revision, author, date when the item was removed.
I debugged the javaHL tests. We have a test named testOODStatus that tests this function pretty well (except I guess it only validates some specific info). When I look at all of the returned status objects, the incoming adds and modifys are all correct, however every other item has a repositoryTextStatus of Kind=none. So both incoming deletes and files that exist and were not modified look the same. I assume that we should get Kind=deleted for incoming deletes, but as an alternative if unmodified items had Kind=normal we could still tell them apart. I have not adjusted the test checks yet as I am not sure how it ought to work. But it seems like there is a bug here. Bert, maybe you can see the same bug in SharpSVN? -- Thanks Mark Phippard http://markphip.blogspot.com/
