[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.1 soon - Please review

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 19 Oct 2011 09:29:50 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.