On Wed, Oct 19, 2011 at 11:59 AM, 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>
>> > 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
>> >>> 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)
In following this discussion, I'd like to point out that while this
seems like an interesting problem, it doesn't feel like a showstopper
for 1.7.1. In other words, I'd like to ship 1.7.1 with our existing
high-impact fixes, rather than wait for this issue to be solved (which
may take some time, iiuc). 1.7.2 doesn't have to be too far away, and
you can problem ship patched binaries with your SharpSvn or Subclipse
If I don't quite understand the gravity of this issue, please enlighten me. :)
uberSVN: Apache Subversion Made Easy
Received on 2011-10-19 19:08:47 CEST