Return-Path: X-Original-To: apmail-flex-dev-archive@www.apache.org Delivered-To: apmail-flex-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B17C6115CF for ; Wed, 2 Jul 2014 19:59:32 +0000 (UTC) Received: (qmail 84895 invoked by uid 500); 2 Jul 2014 19:59:31 -0000 Delivered-To: apmail-flex-dev-archive@flex.apache.org Received: (qmail 84858 invoked by uid 500); 2 Jul 2014 19:59:31 -0000 Mailing-List: contact dev-help@flex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flex.apache.org Delivered-To: mailing list dev@flex.apache.org Received: (qmail 84847 invoked by uid 99); 2 Jul 2014 19:59:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2014 19:59:31 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.214.177] (HELO mail-ob0-f177.google.com) (209.85.214.177) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Jul 2014 19:59:27 +0000 Received: by mail-ob0-f177.google.com with SMTP id uy5so12284889obc.8 for ; Wed, 02 Jul 2014 12:59:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HOT1rhRA0LkR1pAZm9GHdEvM+VmyoeIaoxz8GIqNulI=; b=YS5Dm72vILADeTA/rhfcFDQqfLmW/qPcQH1Aisg4Zw8Wx3/aAu4bWIeG3cHzDAzeNE QuObvtKkxaRKjnMcqxxK3q0IxIZBE9o6hD+BRsfL7KwC/wA/QLR/+WWBRk8yntMz9fiK exnPuabz0Icr3KNek23QmRCWYF+BKDjaC2uvr6yd0PmH4PfQMla9ZHHatfT7THxbnRuk OgZqAuXD2VuHyFNICoN3KKfL9JK2bOGPQe8MRg1lqJUpoSxhNGv2RL4+H8grAosNFmi4 E53uhv6i9jyylevSr5GzjSQj/n93OxvpdG6u09fzRzp0Dj8J7XRXKscaxWvOcZUhezQ3 VlHQ== X-Gm-Message-State: ALoCoQlS7eOYiU3jTWB3kJxNDOzY/CIkgwphD7TBcDCvtjggf8HrilbzRN+QgBmxkiIds342D/zu MIME-Version: 1.0 X-Received: by 10.182.246.98 with SMTP id xv2mr72792obc.80.1404331141789; Wed, 02 Jul 2014 12:59:01 -0700 (PDT) Received: by 10.202.87.204 with HTTP; Wed, 2 Jul 2014 12:59:01 -0700 (PDT) X-Originating-IP: [35.8.29.149] In-Reply-To: References: <1404287178970.80348@c-ware.de> <1404287825428.24814@c-ware.de> <1404290116456.30604@c-ware.de> Date: Wed, 2 Jul 2014 15:59:01 -0400 Message-ID: Subject: Re: New Flex to JS project From: Nicholas Kwiatkowski To: dev@flex.apache.org Content-Type: multipart/alternative; boundary=001a11c2d710da8cdb04fd3b52fa X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2d710da8cdb04fd3b52fa Content-Type: text/plain; charset=UTF-8 It's pretty much one command. The same one you use to keep develop current with your branch :) -Nick On Wed, Jul 2, 2014 at 11:20 AM, Erik de Bruin wrote: > On git: let's assume I work on these branches for 6 months (while keeping > them up to date with develop). How much of a hassle will it be to merge > them back into their respective 'develop' branches? > > EdB > > > > On Wed, Jul 2, 2014 at 10:39 AM, OmPrakash Muppirala > > wrote: > > > On Wed, Jul 2, 2014 at 1:35 AM, Christofer Dutz < > christofer.dutz@c-ware.de > > > > > wrote: > > > > > You don't loose the history when rebasing ... you sort of serialize it. > > Ok > > > the order of commits is messed up, but I never really care about this. > > > It might look less interesting in a GIT visualization tool where you > > could > > > see tons of different branches and merges, but it should be a lot > easier > > to > > > maintain, as a serial history is definiely the one that causes the > least > > > trouble ;-) > > > > > > In IntelliJ I usually set my "update" operation to "Rebase" using > "Stash" > > > and have never really had any problems. One click on "Update SCM" and I > > > still work on my featrue branch, but pull in all changes from develop > or > > > whatever branch I branched from. When it comes to commit, the commit > > itself > > > should be a fast-forward commit. > > > > > > But I guess there are several flavours here ... depending on the guy > you > > > ask or listen too, a different way will probably be recommended. I > guess > > > manually merging changes from develop to the feature branch is as valid > > as > > > rebasing, but I think rebasing is easier and causes less trouble, but > you > > > loose the "real-order" of commits (Which I don't really care about). > > > > > > Chris > > > > > > > I will let Erik decide if he wants to rebase or merge. My recommendation > > is that, since it is a feature branch, it will be useful to retain the > > commit history intact. So, merge makes sense. > > > > If Erik does not want to keep the commit history intact, rebase will just > > work fine. > > > > Thanks, > > Om > > > > > > > > > > > > > > > > ________________________________________ > > > Von: omuppi1@gmail.com im Auftrag von OmPrakash > > > Muppirala > > > Gesendet: Mittwoch, 2. Juli 2014 10:25 > > > An: dev@flex.apache.org > > > Betreff: Re: New Flex to JS project > > > > > > On Wed, Jul 2, 2014 at 1:07 AM, Erik de Bruin > > wrote: > > > > > > > Ok, just checking: > > > > > > > > I create a local branch, let's call it 'vf2js', off > 'origin/develop'. I > > > > select this as my active branch. > > > > > > > > > So far so good. > > > > > > > > > > If I then 'rebase', all changes that have > > > > been made to 'origin/develop' will be pulled into my local branch? So > > > far, > > > > so good. > > > > > > > > > Rebase at this point is not required. The code from origin/develop is > > > already in the 'vf2js' branch. You will need to 'merge' from > > > origin/develop into vf2js once in a while to make sure that you are in > > sync > > > with whats happening with origin/develop. When you are done with the > > > feature, you just 'merge' vf2js into develop. If the history of the > > > 'vf2js' branch is not important, then you use the rebase option. > > > > > > > > > > But now I want the world to see what's in my local vf2js branch, > > > > so I 'publish' it. Is keeping the remote copy of my local branch up > to > > > date > > > > just a question of 'pushing' all commits to that remote branch? > > > > > > > > > Yes, that is correct. > > > > > > > > > > Will > > > > changes that come from the remote 'develop' via my local 'vf2js' also > > in > > > > the remote 'vf2js' that way? > > > > > > > > > > Cannot compute. Can you rephrase the question? > > > > > > > > > > > > > > Thanks, > > > > > > > > EdB > > > > > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:57 AM, Christofer Dutz < > > > christofer.dutz@c-ware.de > > > > > > > > > wrote: > > > > > > > > > No effort at all ... that's what GIT rebase is for. > > > > > > > > > > You can think of this sort of an automated "Create-Patch, Revert, > > > Update, > > > > > Apply Patch" ... if all goes well, it's just this one command, if > > there > > > > are > > > > > conflicts, you get the usual conflict editor you would get anyway > if > > > you > > > > > created conflicts on develop. > > > > > > > > > > Chris > > > > > > > > > > > > > > > ________________________________________ > > > > > Von: Erik de Bruin > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:50 > > > > > An: dev@flex.apache.org > > > > > Betreff: Re: New Flex to JS project > > > > > > > > > > Hi Chris, > > > > > > > > > > Thanks for the feedback. > > > > > > > > > > I'm talking about FalconJX, not Falcon. The latter is the "new" SWF > > > > > compiler, the former is the Flex to JavaScript cross compiler. > > > > > > > > > > I guess a feature branch might work... But I'm afraid that keeping > > that > > > > > branch up to date with the 'develop' branch will add extra work. > How > > to > > > > > best handle that part, so I don't spend what little time I have on > > Git > > > > > stuff instead of code? > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 2, 2014 at 9:46 AM, Christofer Dutz < > > > > christofer.dutz@c-ware.de > > > > > > > > > > > wrote: > > > > > > > > > > > I think the reason for the overlay is that by this we are > tricking > > > the > > > > > > FlashBuilder to use Falcon instead of the old compiler. > > > > > > It should be possible to have Falcon separate from the normal > > > compiler. > > > > > > It's just that FlashBuilder will probably not be albe to use it > > that > > > > way. > > > > > > Probably IntelliJ would support this withn a few hours, Flexmojos > > > > within > > > > > a > > > > > > few weeks and FlashBuilder never ;-) > > > > > > > > > > > > You shouldn't implement this in the develop branch but create a > > > > > > feature-branch instead that forks off the develop branch. This > way > > > your > > > > > > changes are available to anyone interested and as soon as the > > feature > > > > is > > > > > > finished, you merge it back to develop. > > > > > > > > > > > > Chris > > > > > > ________________________________________ > > > > > > Von: Erik de Bruin > > > > > > Gesendet: Mittwoch, 2. Juli 2014 09:33 > > > > > > An: dev@flex.apache.org > > > > > > Betreff: New Flex to JS project > > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm working on creating a way to publish vanilla Flex SDK > projects > > to > > > > > > JavaScript on latest gen browsers. This project consists of > several > > > sub > > > > > > projects, and I'm wondering what is the best way forward with > > regard > > > to > > > > > > contributing them: > > > > > > > > > > > > 1) two new namespaces and accompanying projects in the main Flex > > SDK: > > > > > > vf2js_mx and vf2js_s. These namespaces will contain shim objects > > for > > > > (you > > > > > > guessed it) MX and Spark components. > > > > > > > > > > > > 2) two new code paths in FalconJX: one for AS and one for MXML > > > > > > > > > > > > 3) a new JavaScript library for the components and shims for AS > > > classes > > > > > > > > > > > > 4) a testing framework for the JS components, loosely based on > > > > Marmotinni > > > > > > > > > > > > Questions: > > > > > > > > > > > > A - I would very much like to work in the 'develop' branches of > the > > > > > > projects involved, but especially on the part of '1)' I'm not > sure > > > if I > > > > > did > > > > > > it right. All tests I can think of seem to pass, but maybe > someone > > > has > > > > > the > > > > > > time to do a code review on a branch that I can publish? > > > > > > > > > > > > B - In order for this to work, FalconJX needs to be part of the > > > regular > > > > > SDK > > > > > > distribution. Folks who did this on the FlexJS overlay: what does > > it > > > > take > > > > > > to make FalconJX part of the SDK? > > > > > > > > > > > > That's it, for now :-) > > > > > > > > > > > > Thanks, > > > > > > > > > > > > EdB > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ix Multimedia Software > > > > > > > > > > > > Jan Luykenstraat 27 > > > > > > 3521 VB Utrecht > > > > > > > > > > > > T. 06-51952295 > > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ix Multimedia Software > > > > > > > > > > Jan Luykenstraat 27 > > > > > 3521 VB Utrecht > > > > > > > > > > T. 06-51952295 > > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > > > > > > > > > -- > > > > Ix Multimedia Software > > > > > > > > Jan Luykenstraat 27 > > > > 3521 VB Utrecht > > > > > > > > T. 06-51952295 > > > > I. www.ixsoftware.nl > > > > > > > > > > > > > -- > Ix Multimedia Software > > Jan Luykenstraat 27 > 3521 VB Utrecht > > T. 06-51952295 > I. www.ixsoftware.nl > --001a11c2d710da8cdb04fd3b52fa--