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 <aha...@adobe.com> wrote: > > > > On 8/8/12 5:54 AM, "Justin Mclean" <jus...@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 > >
