incubator-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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Date Tue, 14 Aug 2012 00:00:40 GMT
On Mon, Aug 13, 2012 at 2:38 PM, Dave Fisher <dave2wave@comcast.net> wrote:

>
> On Aug 13, 2012, at 1:43 PM, Omar Gonzalez wrote:
>
> > On Mon, Aug 13, 2012 at 1:39 PM, Dave Fisher <dave2wave@comcast.net>
> wrote:
> >
> >> My opinion/vote is (4) - no guts, no glory - work in trunk and learn to
> >> co-operate.
> >>
> >> The vote is more about the Classic model than it is about Git  vs. SVN.
> >>
> >> To me svn tag == git branch.
> >>
> >> Regards,
> >> Dave
> >
> >
> > People that use Git a lot would strongly disagree with "svn tag == git
> > branch". For starters, SVN tags are supposed to not ever be edited, and
> Git
> > branches are used for almost all new code addition/changes in the "nvie"
> > model, so they're from from ==.
>
> I'm more thinking this from what happens in the central repository and
> what gets marked up in the history from a few comparisons I've done.
>
> When you branch in git you are marking where you are in the main repos,
> correct? If you never push it back the central repos never really cares
> about your branch, correct? So to the repository a branch is like a tag.
>

Branching and tagging are the same thing in SVN, the only real difference
is that it is understood that when you 'tag' something you are not meant to
check out the tag and make commits to it. The minute you commit to a tag it
become a branch. The distinction is not technical, its a convention.


>
> My opinion is that git is just putting off the work of integrating diverse
> changes into a single release. I feel the same about the 3-Tier plan. It is
> just putting ALL the work of deciding what is in a release to a Release
> Manager.
>

I don't know why you think its "putting it off", what its doing is
isolating work into branches that can be merged into a dev (next release)
branch when the time is appropriate (whenever that is, probably once the
branch has been discussed, fixed up, etc).


>
> Really the Apache Way is for the Committers and the PPMC to share this
> responsibility. As this podling must know, you never, ever know when
> someone will exit.
>
> But go ahead and go the way you want, it is up to you all.
>
> Really what is the worst that can happen if someone plays in trunk and
> makes a mistake?
>

Chaos that would affect all committers, which could be avoided by utilizing
branches and isolating work so that it is not disruptive to others work.
Being that we're all here on a volunteer basis I doubt anyone wants to
spend time cleaning up things that others broke because we are all in the
same trunk changing code and causing conflicts that could be avoided with
some clear workflows for the repository. Just because other projects are OK
with chaotic repos doesn't mean we have to be.

-omar

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