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

Breakage in Status API

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 19 Oct 2011 15:02:51 -0400

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.

Mark Phippard
Received on 2011-10-19 21:03:22 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.