Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of omuppi1@gmail.com designates
 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: omuppi1@gmail.com
In-Reply-To: <CC47D271.44240%aharui@adobe.com>
References: <8C1C7524-CBD0-4987-9806-8666EA1E81E4@classsoftware.com>
 <CC47D271.44240%aharui@adobe.com>
From: Om <bigosmallm@gmail.com>
Date: Wed, 8 Aug 2012 10:42:55 -0700
Message-ID: 
 <CACK5iZeppLa1J4+Szb=RPWmmrAdjURFcH9a0QpWh8ap+MfHF1Q@mail.gmail.com>
Subject: Re: Help needed with working with patches
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=485b390f7bfee126bb04c6c4a5f1

--485b390f7bfee126bb04c6c4a5f1
Content-Type: text/plain; charset=ISO-8859-1

Yet another (albeit a bit roundabout) approach would be to use the GitHub
mirror here: https://github.com/apache/flex

You can fork a new GitHub project for each patch you are planning to
create.  Each one forks off of the main flex github.  You can create
patches individually and attach them to corresponding JIRA tickets.

Or you can create a patch on project 1, fork it into project 2 and continue
working on patch 2 there.  If you want to modify patch 1, do it in project
1 and then send a 'pull request' from that project 1 to project 2.  Once
you have merged the first patch into the second one, you can continue
working on your second github project/patch.

Simple, conflict-less merges can be automatically be done from GitHub.
Complex, conflict-filled merges can be done on your machine before you push
it to your github.

The good thing is GitHub is free for public/open source projects and you
can create as many projects as you want.  This also facilitates multiple
non-committers to collaborate on one patch - which is not possible with our
standard SVN patch process.

Thanks,
Om

On Wed, Aug 8, 2012 at 8:23 AM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> On 8/8/12 5:54 AM, "Justin Mclean" <justin@classsoftware.com> wrote:
>
> > Hi,
> >
> > Interesting issue and probably not one correct answer.
> >
> > I'd go with generating patches against the latest SVN head as they can be
> > easily applied.
> >
> > I'd try and keep in sync with the trunk (ie svn update) but no need to
> revert
> > to it as that would mean more work for you.
> >
> Another option is to make another working copy and implement your second
> patch there, but there's always a chance that acceptance of the first patch
> will make the second not apply cleanly.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>

--485b390f7bfee126bb04c6c4a5f1--