Matthew Janulewicz wrote:
Of course, this is always a philosophical issue, and my philosophy is
always wrong. Ha ha.
I've always viewed branches as keepers of a specific codeline. Branch
per task is just (for me) way outside that resolution.
The two questions that will eventually come up are:
1. Who defines what a task is (believe me, it's always ambiguous), how
big/small it should be, thus the name/use of the branch.
These things are intentionally ambiguous. It depends on the project. NASA may
define /all/ tasks large enough to warrant branches while another project may
deem most things to be small enough not to.
2. Who does that integration? As already mentioned, if one guy (usually
someone in CM) gets to merge from 50 different branches, it gets ugly.
It takes a lot of time, and there are usually more conflicts. If you
make the engineers branch that much and integrate every little change,
you won't be popular for long.
This choice is also discussed in "Streamed Lines".
Noel
11 messages in com.perforce.perforce-userTask Branching for babies (was: Re: [...