On Wed, Oct 19, 2011 at 7:38 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Oct 19, 2011 at 12:00 AM, Hyrum K Wright
> <hyrum.wright_at_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/
Received on 2011-10-19 15:30:22 CEST