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

Re: Breakage in Status API

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 25 Oct 2011 13:11:46 -0400

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?

Mark Phippard
Received on 2011-10-25 19:12:17 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.