incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <>
Subject Re: SVN and issues with branching / consider how we use SVN going forward
Date Thu, 09 Aug 2012 07:21:28 GMT
> If it's possible, yes, I really do think Git would help.

As Michael and Om says Git would be an improvement over SVN. At work, we
switched to Git some months ago and the overall experience is great. We
have more control about how code evolve over time taking into account that
we have many hands in different teams working in different branches. The
way we work today would be impossible with old SVN.

Flex is reaching version 5, and that means we need to change core things
(UIComponent, HTLM5 approach,...) that touch many other things and take
several time, ...and continue with normal small modification and addition
changes. At this point Git would be a better option than SVN since
committers could branch an isolate his work in an efficient way. Git has
several tools to make this easy (staging, stashing, cherry picks, and so

Other thing that would be possible with Git is that part of the team
(PPMC?) could control what commits goes to the main branch and the ones
that are not eligible, and contributors could send the commit without the
need to be applied directly to the final product. I'm with Alex, that some
patches could "work for me" but could break other things (something that
mustella could detect...or not) and, with Flex as a mature framework, will
be necessary to have people monitoring this.

SVN seems ok when project are starting...but for mature software that needs
to evolve things that was developed years ago and need to be rethinked and
rewritten affecting several parts of the entire software...Git is the

Take into account that Git needs some "mind change" from the people that
comes from SVN since the philosophy behind changes and is what makes the
system great.

If we vote my "non binding" vote will go to git without doubt :)


Carlos Rovira

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