On Wed, Oct 19, 2011 at 12:59 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Mark Phippard [mailto:markphip_at_gmail.com]
>> Sent: woensdag 19 oktober 2011 15:30
>> To: Hyrum K Wright
>> Cc: Bert Huijben; dev_at_subversion.apache.org
>> Subject: Re: 1.7.1 soon - Please review
>>
>> 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 don't think the status editor receives the exact revision in which a node
> was removed. (A delete doesn't receive entry props via the delta editor).
> The only know revision would be the status against revision.
>
> The status editor doesn't receive information on nodes that didn't change in
> the repository vs what is in the working copy so status 'none' might even be
> expected for unmodified. (I really don't know)
>
> I will write a few tests...
I went back and debugged the JavaHL tests in 1.6.17. For the same
item, it receives a repository text status == 4. In 1.7 it is 0. So
something changed in the API.
As a workaround in Subclipse we are doing this, which I think works:
If (TextStatus == 0 and ReposLastCommitRevision > -1) TextStatus = DELETED
From what I see, when the item is deleted it still returns the
revision it was deleted and for files that are unmodified it returns a
-1 for the last commit revision. So I think this will work. Files
that are Added/Modified do not return text status == 0 so they would
not be impacted by this.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-10-19 21:03:22 CEST