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: Branching Strategy and SCM
Date Tue, 14 Aug 2012 14:53:01 GMT
On Tuesday, August 14, 2012, Greg Reddin wrote:

> On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
> <omarg.developer@gmail.com <javascript:;>> wrote:
> > The way I see it, if there are a bunch of developers working in trunk,
> and
> > they happen to leave things unfinished or unstable, then somebody has to
> go
> > through all of that and figure out what is actually ready for a release
> and
> > what is not. Without a well defined SVN strategy this is going to be a
> mess
> > that someone will have to clean up.
>
> Everyone is working in trunk. Some things are unstable. A discussion
> starts up on list that it's about time we cut a release. We either
> decide to: 1) move some stuff from trunk to a branch so we can make a
> release from trunk, or 2) cut a branch from trunk and make a release
> from the branch. Either way we spend some time either getting trunk
> stable for a release or getting a branch stable for a release. Then we
> make a release and work goes on.
>
> Personally, I wouldn't commit any unstable code to trunk. If I'm
> working on something that's going to span more than one or two
> commits, I'd do it in a feature branch. When the feature branch is
> done I merge to trunk.
>
> Here's a use case: Greg wants to implement better Maven support and
> Alex wants to refactor UIComponent at the same time. Both of these are
> long-running efforts that touch a lot of code. Nobody knows how big
> either one really is or how long it will take. So here's a script of
> how it might play out:
>
> 1. Greg: svn cp trunk branches/maven-support
> 2. Alex: svn cp trunk branches/UIComponent-refactor.
> 3. Over the course of two or three weeks people commit to both of
> these branches. People also commit to trunk.
> 4. Periodically Greg and Alex run svn merge trunk in their branches to
> keep the branches up to date with trunk.
> 5. Om decides to make a release from trunk, so all effort in trunk
> goes toward making the release. Work continues in the two branches.
> 6. Release is cut from trunk and a tag is created.
> 7. Greg and Alex continue to run svn merge trunk to keep their
> branches up to date.
> 8. Alex completes his work first because he's much faster than Greg :-)
> 9. After some discussion on flex-dev everybody agrees Alex's work is
> worth integrating.
> 10. Alex does a final svn merge trunk in his branch to get the latest
> updates.
> 11. Alex goes to trunk and runs svn merge --reintegrate
> branches/UIComponent-refactor,
> 12. Alex makes a commit to trunk.
> 13. Greg does another svn merge trunk in his branch to get the
> UIComponent refactor.
> 14. Alex makes a release from trunk.
> 15. Greg repeats step 13.
> 16. Eventually Greg & team *finally* finish their work.
> 17. After discussion on flex-dev everybody agrees that Greg's work is
> indispensable and needs to be integrated.
> 18. Greg does a final svn merge trunk in the maven branch to bring
> over latest changes.
> 19. Greg does a svn merge --reintegrate branches/maven-support in trunk.
> 20. Greg makes a commit to trunk.
> 21. Greg makes a release from trunk.
> ...
>
> Notice a few things:
> * Potential pain points come in step 7 because the released code might
> be hard to integrate into the branches, and particularly steps 9 - 12
> and 16 - 20 because we're reintegrating significant changes back into
> the codebase. However these pain points are at isolated, atomic stages
> along the way.
> * Notice the discussion that takes place at step 5, step 9, and step
> 12. When we are ready to make a release we talk about it. Everybody
> works together to make it happen. When we are ready to integrate
> significant progress we talk about it and everybody works together to
> make it happen.
>
> It's not perfect. It's not necessarily fast. But it's proven to work
> for a lot of apache projects and it doesn't get much simpler.
>
> Greg
>

It sounds like hell to me.

-omar

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