flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Date Mon, 13 Aug 2012 22:45:08 GMT
Hi Alex,

What is that "clarity"?  Can you give me an example?  If I want to
> contribute a set of Spark Charts, why should I have to cut a branch first?
> Why can't I just check in ChartBase into the "develop" branch, then add in
> Pie, Bar, etc over time in subsequent check ins as I finish them up?
First considere that in Git, "develop" use to be as stable as possible and
you can make nightly builds from this branch and "master" use to be
production ready with the release we made.

Normaly, if you are working in a set of spark charts, your work will spawn
over some weeks. So if you work directly on develop, you should not commit
your work to SVN until is done because you will make "develop" unstable
until you close the feature.

In Git you will prefer to branch from "develop" and make a feature branch
called "spark-charts" that will allow you to commit to your local
repository (and if you want publish that branch in the remote) knowing that
you are not breaking nothing. When you finish your work, you can merge in
"develop" maintaining that branch stable.

Think now that other people are working in the refactor of UIComponent to
break into small components and behaviours. That task will be long in time
and will need to be finished before that people could merge it in
"develop". If not we will have flex broken for long time.

For this reason I say that IMHO we really does not have election. SVN is a
bad decission here, while GIT is the opossite...

If someone thinks that I'm wrong please let me know some arguments, because
maybe...I'm really wrong with my arguments!  :)

Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid

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