incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Date Tue, 14 Aug 2012 00:23:33 GMT
On Mon, Aug 13, 2012 at 4:48 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> On 8/13/12 4:08 PM, "Om" <bigosmallm@gmail.com> wrote:
>
>
> > A committer is free to decide what is unstable and what is complete.
>  Fast
> > branching gives us the flexibility of sharing unstable features with
> > others, while keeping develop and master as stable as possible.  The
> > current 'whiteboard' concept is not a real alternative because it forces
> > comitters to work on single features at one time.  I will not be able to
> > experiment with core Mustella/FlexUnit/UIComponent and work on a new
> > component at the same time in my whiteboard.  It causes me to needlessly
> > serialize my work.
> >
> > Om
> SVN doesn't allow you to have more than one branch in your whiteboard?


(This is probably tangential to the current discussion)
As I understand, in the whiteboard, there is one single folder for each
committer.  What folder structure would you suggest for two features being
worked on by a single committer?


> Most
> of these arguments still seem to be about fear of merge-hell in SVN.  Which
> is valid, but the logic about when to branch/merge seems to apply to both.
>

Branching is good - especially for a project like Flex, where concurrent
development needs to happen on various different parts of the codebase.  We
should not stay away from branching just because SVN discourages it.  At
the same time we should not go crazy creating branches just because Git
makes it easy to do it.

We must embrace any SCM that encourages branching and is efficient at doing
so.

Are you saying that we should go with SVN while at the same time adopting a
branching strategy like the git branching model?  I am not sure SVN can
handle that.

Om

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