On Wed, Oct 19, 2011 at 3:02 PM, Mark Phippard <[email protected]> wrote: > On Wed, Oct 19, 2011 at 12:59 PM, Bert Huijben <[email protected]> wrote: >> >> >>> -----Original Message----- >>> From: Mark Phippard [mailto:[email protected]] >>> Sent: woensdag 19 oktober 2011 15:30 >>> To: Hyrum K Wright >>> Cc: Bert Huijben; [email protected] >>> Subject: Re: 1.7.1 soon - Please review >>> >>> On Wed, Oct 19, 2011 at 7:38 AM, Mark Phippard <[email protected]> >>> wrote: >>> > On Wed, Oct 19, 2011 at 12:00 AM, Hyrum K Wright >>> > <[email protected]> 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? -- Thanks Mark Phippard http://markphip.blogspot.com/
