> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: dinsdag 25 oktober 2011 19:12
> To: Bert Huijben
> Cc: Hyrum K Wright; dev_at_subversion.apache.org
> Subject: Re: Breakage in Status API
>
> 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?
I spend some time creating a test framework for comparing behavior, but what
I found was a complete different issue.
In Subversion 1.6 status is reported as text_status and property_status,
while Subversion 1.7 reports status as node_status, text_status and
property_status.
The compatibility code in libsvn_client and libsvn_wc automatically
transforms the more complete status back to the old format (where node
status overwrites text status) while the code in javahl just ignores
node_status.
Bert
Received on 2011-10-26 13:59:10 CEST