incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carol Frampton <>
Subject Re: SVN and issues with branching / consider how we use SVN going forward
Date Thu, 09 Aug 2012 15:22:09 GMT

On 8/9/12 11 :06AM, "Greg Reddin" <> wrote:

>On Wed, Aug 8, 2012 at 6:15 PM, Dave Fisher <> wrote:
>> I totally agree. Maintaining an unstable version will actually make
>>more work. Just when you think it is stable enough to move into trunk,
>>you have to make it stable again in trunk.
>> The community should be perfectly capable of deciding when trunk should
>>be made stable for an upcoming release and stop making ill considered
>We argued about this for days at $work, then we finally stumbled on a
>solution. Flip the model around. Trunk becomes the unstable, do
>whatever you want, development branch. Create a separate stable or
>release branch where code gets "promoted" to.
>The process is still evolving. We haven't quite figured out the best
>way to "promote" code in svn. Here's what I *think* we'll move to
>pretty soon:
>1. Trunk is still the unstable development branch.
>2. People create feature branches for work that can't be completed in
>short order. Merge often from trunk to your feature branch.
>    2a. When feature branch is done, merge --reintegrate back to trunk.
>3. Trunk is always pretty close to being ready to release even though
>it is considered unstable.
>4. When we are close to a release we restrict changes on trunk to
>those related to the release.
>5. Tag releases.
>6. For a patch/bugfix release create a branch from the previous tag.
>Make the bugfix in the branch. Be sure to make it in trunk also
>(sometimes it's easier to make the change in trunk then merge it to
>the branch).
>    6a. Tag the patch/bugfix release
>Not fully fleshed out, but a basic plan.

I believe this is exactly what I just read in with the exception
being at your #4 you would create a release branch and allow development
to continue on trunk.  When released, a tag would be created for the
release branch and any changes made on the release branch would be merged
back to trunk.

I think this is exactly what we did at Adobe.  The only difference is we
had a branch for each release and in this model I think you could keep
using the same release branch for each release, merging changes from trunk
to the release branch at the start of the cycle and then reintegrating the
changes back to trunk at the end of the cycle.

When you see it laid out in the diagram in the article it makes a lot of
sense especially since it seems pretty clear to me that some people want
to do work which will take awhile and span a release cycle.

The one thing we learned about svn merge is that when you merge you always
have to do it from root so all the merge records get written at the root
and it is easier to keep track of what has been merged and what hasn't.


View raw message