Task Branching for babies (was: Re: [p4] Branching for toddlers)
Noel.Yap at morganstanley.com
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.
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.
> 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?)
>> Rene Medellin
>> Release Engineer
>> 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
>>> 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
>>> > 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
>>> perforce-user mailing list -
>>> perforce-user at perforce.com
>> Do you Yahoo!?
>> Declare Yourself - Register online to vote today!
>> perforce-user mailing list - perforce-user at perforce.com
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user