Task Branching for babies (was: Re: [p4] Branching for toddlers)

Mon Oct 4 18:11:34 PDT 2004

I'd like to clarify my point.  I am _not_ advocating one branch per task.  IME, one branch per medium- to large-sized task is good.  Small tasks can be made directly on the main development line.

Branches are not free -- they come with management cost as you have seen.  Large-sized tasks generally are worth that management cost.  Small-sized tasks generally are not.

Noel

Matthew Janulewicz wrote:

> My 2 cents. Maybe more like a nickel ...
> 
> I am a ClearCase refugee (maybe more like an escapee ;) ) and 
> personally,  the branch by task methodology is one thing I *didn't* like 
> about it. If  you have 50 or more engineers creating a new branch with 
> every task, you  quickly get a severe proliferation of branch types. 
> With that many  branches, they lose their meaning and usefulness. You 
> never know exactly  where your branch is attached. It's hard to wrangle. 
> (Not to mention  waiting around for five minutes while ClearCase 
> constructs your list of  branch types in the type browser ...)
> 
> To group any of these tasks/branches together, you integrate/merge 
> them,  potentially creating, alas, more branches.
> 
> When I admined ClearCase, we integrated it with ClearQuest (bug 
> tracking)  which obscured all these branches into code revisions 
> attached to issues.  This was a big help, and really made the notion of 
> having to branch with  each task obsolete. Engineers liked this because 
> it sped them up, they  didn't have to be bogged down with semantics. 
> They could get to coding.
> 
> We are in the infancy of implementing a similar system here, 
> integrating  Perforce with an issue tracking system. We have, depending 
> on the project,  one or several codelines that correspond to major 
> releases. The codeline I  build from will (eventually) require that 
> submissions have a job (issue)  attached which will correlate with a 
> task/defect in the other tool.  Perforce's atomic checkins support this 
> very nicely. In this system, the  branches have a concise, specific and 
> obvious meaning.
> 
> Users are free to create any branch they want for experimental or  
> integration work, but in my experience, forcing engineers to create all  
> these branches only gets you on their bad side, and they will quickly 
> find  clever ways to work around the system.
> 
> 
> -Matt
> 
> 
> 
> On Mon, 4 Oct 2004 16:56:43 -0700 (PDT), Rene Medellin  
> <medellre at yahoo.com> wrote:
> 
>> Hey, good segway...
>>
>> As a ClearCase refugee, one of the things I'm trying
>> to do in P4 right now is implement a branch-per-task
>> methodology - which is one of the few things I liked
>> in CC. i.e. I want to have branches that contain
>> task-specific functionality in them (as described in
>> this mail thread). The only thing I've been thinking,
>> though, is that P4's inter-file branching may make
>> this too costly. Are there many people out there
>> working with Task-branches. What is your lifecycle
>> like? i.e. do you integrate up to an integration
>> branch and then a release branch? Any whitepapers or
>> articles out there on the subject (specific to a P4
>> implementation not just the raw branch theory?)
>>
>> Cheers,
>>
>> Rene Medellin
>> Release Engineer
>> MarketAxess
>> New York
>>
>> --- Noel Yap <Noel.Yap at morganstanley.com> wrote:
>>
>>> The only comment I have is that, IMO, users are the
>>> wrong abstraction for branches.  The correct
>>> abstraction are the tasks or the actual work.  For
>>> example, if one has task branches rather than user
>>> branches, there's absolutely no problem if the
>>> ownership
>>> of the task switches hands and there's also no
>>> problem with multiple developers working together on
>>> the same task.
>>>
>>> Other than this, I don't see anything wrong with
>>> what you have.
>>>
>>> You should also google for "Streamed Lines".
>>> Typically, if you don't see what you have on these
>>> pages, or if you see them in the Anti-Patterns
>>> section, it's not a good sign.
>>>
>>> Don Williamson wrote:
>>>
>>> > Hi,
>>> >
>>> > we've recently been experimenting with branching
>>> (team of around 10
>>> > programmers) and we have the following setup
>>> (assuming 'fgs2' is the
>>> > name for our internal libraries):
>>> >
>>> > //depot/Source/fgs2/            Mainline
>>> > //depot/Source/fgs2-rev1/        Any release of
>>> the libraries
>>> > //depot/Users/dwilliamson/fgs2/        My personal
>>> branch
>>> >
>>> > The setup includes each programmer having a
>>> branchspec that performs the
>>> > mapping from mainline to users directory. This
>>> isolates all programmers
>>> > from the mainline (and any problems when it
>>> breaks) and when they're
>>> > working on their component they have to regularly
>>> integrate from the
>>> > mainline to their own branch, resolving any
>>> conflicts. They submit to
>>> > their own branch regularly, and when finishing
>>> their task they reverse
>>> > integrate with the mainline.
>>> >
>>> > It seems to be working well but I'm a bit worried
>>> about the stress this
>>> > might put on the database (if any). For example,
>>> any changes made to the
>>> > mainline have to be propagated onto each user
>>> branch (resulting in a
>>> > pretty ugly revision graph).
>>> >
>>> > Is this method of working ok? Are they any
>>> horrible monsters that will
>>> > finish us off in the future if we use this method?
>>> >
>>> > Cheers,
>>> > - Don
>>> > _______________________________________________
>>> > perforce-user mailing list  -
>>> perforce-user at perforce.com
>>> >
>>>
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
>>
>>> _______________________________________________
>>> perforce-user mailing list  -
>>> perforce-user at perforce.com
>>>
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
>>
>>>
>>
>>
>>
>>        
>> _______________________________
>> Do you Yahoo!?
>> Declare Yourself - Register online to vote today!
>> http://vote.yahoo.com
>> _______________________________________________
>> perforce-user mailing list  -  perforce-user at perforce.com
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> 
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user