On Wed, Oct 19, 2011 at 3:02 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
This workaround turns out to be not so perfect. Have you had a chance
to look at this problem in the API?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-10-25 19:12:17 CEST