Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of shazron@gmail.com designates
 209.85.128.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-YR6OLVcJQBDm1g3epu+9+50-htjKeHjSfC5sq62pFoJg@mail.gmail.com>
References: 
 <CAE6O_-bg-5xubV_F=dSJD3Pjj9r+6ui2DvVgZY=OvdBtTDH1TQ@mail.gmail.com>
 <CD845386.1C0E9%fil@adobe.com>
 <CAE6O_-YR6OLVcJQBDm1g3epu+9+50-htjKeHjSfC5sq62pFoJg@mail.gmail.com>
From: Shazron <shazron@gmail.com>
Date: Fri, 5 Apr 2013 11:55:23 -0700
Message-ID: 
 <CAE6O_-ZqYgKY=aN9i5SZbRoPZsX71fcszQkhf23UdVPDMtaMsA@mail.gmail.com>
Subject: Re: Mobile-Spec contains Cordova 2.7 tests
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc8b0a891cc104d9a1a322

--047d7bdc8b0a891cc104d9a1a322
Content-Type: text/plain; charset=ISO-8859-1

Ian,
if I revert CB-2226, now this test fails:

FileTransfer download method should not leave partial file due to abort.
    Expected false to be true, 'downloadWin should not have been called.
Got args:
{"0":{"isFile":true,"isDirectory":false,"name":"BlueZedEx.mp3","fullPath":"/var/mobile/Applications/EB697B98-8D8E-49A8-A387-E591610A1E66/Documents/BlueZedEx.mp3","filesystem":null}}'.

(test was added Feb 12 2013:
https://github.com/apache/cordova-mobile-spec/blob/7502d51a0b332007959144cbcdf579ddcd067332/autotest/tests/filetransfer.tests.js#L229
)

If CB-2226 commit is put back in, that test passes. Harmless?

I tested with the current 2.6.x iOS branch and the mobile-spec 2.6.x with
the new reverts.
The commit "2003ff7: [CB-1517] Add an assertion that progress.total <
progress.loaded" was not reverted since my other revert included this
commit's revert as well.


On Fri, Apr 5, 2013 at 11:17 AM, Shazron <shazron@gmail.com> wrote:

> I'll revert those commits mentioned by Ian and tag 2.6.0 after.
>
>
> On Fri, Apr 5, 2013 at 10:19 AM, Filip Maj <fil@adobe.com> wrote:
>
>> +1 to reverting.
>>
>> +1 to Shaz's point, slowly people will learn. For the record, if you want
>> to cherry-pick a commit from master into 2.6.x, you would do:
>>
>>     $ git checkout master
>>     $ git log --pretty=oneline --abbrev-commit HEAD^..HEAD # lets see the
>> last commit
>>     abcd123 some commit message
>>     $ git checkout 2.6.x
>>     $ git cherry-pick abcd123
>>
>> To be clear, this will create a *new* commit in 2.6.x, so don't be
>> surprised if the SHA changes after you cherry-pick it in.
>>
>> On 4/5/13 9:51 AM, "Shazron" <shazron@gmail.com> wrote:
>>
>> >Let's revert, not rollback. I'm sure we expected some teething pains
>> >adjusting to the new scheme.
>> >
>> >On Friday, April 5, 2013, Ian Clelland wrote:
>> >
>> >> It looks like a number of commits intended for 2.7.0 were merged back
>> >>into
>> >> the 2.6.x branch
>> >>
>> >> My commits:
>> >> dbf631c: [CB-2305] Add spec tests for InAppBrowser.insertCSS and
>> >> InAppBrowser.executeScript APIs
>> >> 46e478f: [CB-2226] Add spec test for FileTransfer.abort error callback
>> >> da89eaa: [CB-1517] [CB-1518] Add spec test for gzip-encoded resources
>> >> 2003ff7: [CB-1517] Add an assertion that progress.total <
>> >>progress.loaded
>> >>
>> >> were all committed to master after the 2.6.x branch was split, but then
>> >> master was merged back into 2.6.x (acd1b96, Apr 2)
>> >>
>> >> There may be other commits in there that were merged accidentally; I
>> >> haven't looked at all of them yet. I think that any commits from master
>> >> which *should* be in 2.6.x should have been cherry-picked, rather than
>> >> merging master.
>> >>
>> >> From the iOS thread, I see that da89eaa was reverted, but the rest of
>> >>them
>> >> are still on the 2.6 branch.
>> >>
>> >> It's probably too late to just rewind the 2.6.x branch back to f6cbe2e
>> >> (rewriting public history and all that,) but should we revert the other
>> >> commits before we tag 2.6.0?
>> >>
>> >> Ian
>> >>
>>
>>
>

--047d7bdc8b0a891cc104d9a1a322--