On Wed, Oct 19, 2011 at 12:59 PM, Bert Huijben <b...@qqmail.nl> wrote: > > >> -----Original Message----- >> From: Mark Phippard [mailto:markp...@gmail.com] >> Sent: woensdag 19 oktober 2011 15:30 >> To: Hyrum K Wright >> Cc: Bert Huijben; dev@subversion.apache.org >> Subject: Re: 1.7.1 soon - Please review >> >> On Wed, Oct 19, 2011 at 7:38 AM, Mark Phippard <markp...@gmail.com> >> wrote: >> > On Wed, Oct 19, 2011 at 12:00 AM, Hyrum K Wright >> > <hyrum.wri...@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. -- Thanks Mark Phippard http://markphip.blogspot.com/
