My philosophy on source control assumes the head is the next release, as it
is what's built every night. People working on the branch merge head
changes into their branch, and when they are done with their work, they
merge their branch back into the head.
The idea is that maintaining a branch for very long gets painful, and thus
the scope of changes on the branch stay smaller. Nothing sits out on a
branch that isn't going to be merged into the head.
Philosophically, there's one codebase, with branches being indicators of
where the codebase is going. More of a Sequoia rather than an apple tree.
The trunk is more important than the branches, as it represents the usable,
releasable product.
This leads to quite a few branches over time as well as the head getting the
new developments quicker. It also makes big changes in the codebase to
happen more incrementally.
The biggest burden is borne by feature/refactoring devs, but this is
actually a good thing as the developer has to stay pretty close to the
trunk, and as a result, with each other. When devs are merging from the
head every day and merging their changes into the head every few days, the
main line has to stay stable. The quality of the changes goes up and
integration hell is avoided (along with most of the fighting) at the end.
Again, this is my own hard-won philosophy, and may not be what the James
community adheres to.
Matt Bishop
[EMAIL PROTECTED]
"We are all here on earth to help others. What I can't figure out is what
the others are here for."
- W. H. Auden
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
