> -----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 have not adjusted the test checks yet as I am not sure how it ought
> to work. But it seems like there is a bug here.
>
> Bert, maybe you can see the same bug in SharpSVN?
One of the SharpSvn users reported this problem, but I don't have enough
test coverage on the status -U behavior yet.
(I do test the common cases, but not all properties in all cases)
Bert
Received on 2011-10-19 19:00:28 CEST