flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Omar Gonzalez <omarg.develo...@gmail.com>
Subject Re: [LAZY] Commit en_AU and en_GB locales to SVN
Date Thu, 23 Feb 2012 07:12:19 GMT
On Wed, Feb 22, 2012 at 10:46 PM, Alex Harui <aharui@adobe.com> wrote:

> On 2/22/12 7:58 PM, "Justin Mclean" <justin@classsoftware.com> wrote:
> > Hi,
> >
> >> Well, My assumption is because the size of the SVN dumps
> > I wouldn't expect the framework code that's already in SVN to be
> reimported in
> > the same way again. Other Adobe donations would be a large import but
> there no
> > issues there.
> >
> > Hopefully Carol (or someone else) can confirm that changes to
> > build_framework.xml are OK or that a SVN revert of any changes to
> > build_framework.xml (if it was required) would not be an issue.
> >
> > Justin
> I'm not an SVN expert, but the plan is for Adobe to load at least one more
> huge dump (compiler) and maybe a huge mustella check=in, and hopefully a
> smaller automation check-in before cutting a "parity" release.
> However, I think you can branch what's there, make your changes in trunk
> and
> we can cut the parity release from the branch.  I'm not an SVN expert, but
> I
> think we can control what revisions get integrated into the parity branch.
> If someone else familiar with SVN can confirm, then that would be my
> recommendation.
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
> I believe the path of least resistance is to branch trunk/frameworks into
whiteboard/ApacheFlexPatches/frameworks and apply the patches there, and
once all Adobe's donation code is in trunk/frameworks then merge branches
in the whiteboard area back into Adobe's donation so we can start with the
correct baseline. We can merge patches from different people into this
staging area and then merge it back into trunk. At least its been my
experience that branching in SVN in general sucks if you try to pick
commits here and there to merge, at the least, its a PITA. That would be my
recommendation but if someone wants to correct me on a better SVN approach
I'm all ears. I've been mainly a Git user for a long time so my SVN isn't
as fresh as it used to be.

Omar Gonzalez
Apache Flex PPMC Member

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