>>That *may* be the right approach. There are times when branching is appropriate. I'll say it again....
>>1) Most teams branch way too much.
>
>Agree, but I don't see a problem with this, if all this branching is justified. For example, when Branching per Task, each task is composed of main task and a subtask for each developer, so main task is only a merge task of the devs individual work. In this work style, with 2 devs per task, you have 3 branches for each task at total (1 main + 2 dev).
>
>
>>2) Most teams keep branches alive for too long.o
>
>Agree too. But sometimes this "long living" is not responsibility of the devs, but the Business people, that want something "super important" and when you have it, they change of mind and want this for next version and not for actual one. In this scenario, a branch is a way to not throw all this work and keep it for future versions. I see this more frequently than I would like.
>
>
>>3) You can't do CI on the branch because it doesn't integrate.
>
>I think that at this point is important to define what is "Integrate" for each one. For example, I see that for Java people "Integrate" in CI is when they push changes to the SCM tool on Integration Branch, the CI Server runn all the tests, and when done, if no error, this branch is automatically versioned.

They're missing the point. You should never have an Integration Branch.

>
>But for the CI use we use for Visual FoxPro, this does not apply, and we use the CI server as a "test server", on which we just want to know if all the changes pass the tests, not only on Integration branch, but on each release branch. Next step for us is going further and doing CI at task branch level, so we have more confidence that when code goes from task branch to integration task it does only if passing all the tests.

Release shouldn't have a branch until you've actually released. Then, there's really no need to run tests on it.

>
>All merging is done by the Integrator when code must be integrated on main branch, because in VFP automated merge can't be done without someone taking eye of the process, and when I say "merge" I don't refer to "merge of files on which nobody changes the same files", but the contrary, "merge of files on which same files can be changed by more than one developer"

Yikes! Merging from multiple developers can get very ugly very quickly.

>
>
>I think that, even if we not agree on all of this, this thread is really interesting, so we can change experiences on different work styles and workflows.

Read this book then come back http://www.informit.com/store/continuous-delivery-reliable-software-releases-through-9780321601919