11 messages in com.perforce.perforce-userTask Branching for babies (was: Re: [...| From | Sent On | Attachments |
|---|---|---|
| Don Williamson | 04 Oct 2004 13:25 | |
| Noel Yap | 04 Oct 2004 13:42 | |
| Rene Medellin | 04 Oct 2004 16:56 | |
| Matthew Janulewicz | 04 Oct 2004 17:41 | |
| Rene Medellin | 04 Oct 2004 18:08 | |
| Noel Yap | 04 Oct 2004 18:11 | |
| Matthew Janulewicz | 04 Oct 2004 18:41 | |
| Stephen Vance | 05 Oct 2004 00:51 | |
| Stephen Vance | 05 Oct 2004 01:02 | |
| Noel Yap | 05 Oct 2004 02:13 | |
| Chuck Karish | 05 Oct 2004 07:26 |
| Subject: | Task Branching for babies (was: Re: [p4] Branching for toddlers)![]() |
|---|---|
| From: | Rene Medellin (mede...@yahoo.com) |
| Date: | 10/04/2004 04:56:21 PM |
| List: | com.perforce.perforce-user |
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




