cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Mobile-Spec contains Cordova 2.7 tests
Date Fri, 05 Apr 2013 18:55:23 GMT
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
>> >>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message