incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Reddin <gred...@gmail.com>
Subject Re: Discuss: Branching Strategy and SCM
Date Tue, 14 Aug 2012 13:56:08 GMT
On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez
<omarg.developer@gmail.com> 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

Mime
View raw message