[p4] Re: Task Branching for les jeunes... - Jim Crossley - com.perforce.perforce-user

3 messages in com.perforce.perforce-user[p4] Re: Task Branching for les jeune...

From	Sent On	Attachments
Rene Medellin	05 Oct 2004 06:34
Jim Crossley	05 Oct 2004 07:26
Noel Yap	05 Oct 2004 07:31

Subject:	[p4] Re: Task Branching for les jeunes...
From:	Jim Crossley (jim....@cptii.com)
Date:	10/05/2004 07:26:07 AM
List:	com.perforce.perforce-user

You have an automated build process, right? You have self-testing code,

right? You're maniacal about unit tests, right? Focus on those things, and eventually you'll wonder why you ever spent so much time worrying about task branches.

Yes, Perforce's branching rocks, but branching implies merging, and merging is always a pain, no matter what tool you use.

IMHO, Perforce really shines when all the developers for a project are working in the same codeline, the "main line". Only rarely will they need to edit the same file concurrently, and p4 is good about letting you know someone else has the file open when you need to modify it, at which point coordination and/or collaboration should occur. Change notifications also help here. Sometimes, of course, conflicts do emerge, but they are typically smaller and easier to merge than when each developer is on a personal codeline. Task branches do not encourage collaborative development. Standard Disclaimer: my opinions, my experience, every project is different.

Occasionally, we will use task branches, but only for very large tasks, and we strive to get the changes back in the mainline as quick as possible.

BUT I REPEAT: "Mainline development" only works when you 1) stress the importance of self-testing code, and 2) have a good continuous integration process in place. See http://www.martinfowler.com/articles/continuousIntegration.html for details.

Jim

-----Original Message----- From: perforce-user-admin at perforce.com [mailto:perforce-user-admin at perforce.com] On Behalf Of Rene Medellin Sent: Tuesday, October 05, 2004 9:35 AM To: perforce-user at perforce.com Subject: [p4] Re: Task Branching for les jeunes...

Nice lively topic, no?

Thanks to everyone who's taken the time to respond. Here's a few point/counterpoints after digesting everyone's input:

* One of the biggest benefits I'm hoping to get from task branches is clearer ownership of the integration step. Right now, this is done in our CM group and it always turns into a merge fiasco lasting anywhere from 3 to 5 or even 6 days. With a task-branch, I am hoping to put the responsibility on the branch owner to deliver their changes themselves (to the intg branch). The advantage is that if the integration doesn't pass some validation test (criteria yet to be determined) then it's easy to roll it back. The person can then go back to their task branch, correct the problem and re-deliver to the integration branch.

* How the task is defined will be very informal -- left up to the task owner. I'm really not aiming to institute a lot of rigid policy here (i.e. No penalty for not using the right TPS Report cover or other bureaucratic nonsense like that). I'm trying to make things more fluid, more dynamic, not to introduce bottlenecks. Anybody seen my Red Swingline stapler? :)

* I don't see this as branching for the sake of branching. We're trying to go to a tighter release cycle, in the order of 2-3 weeks. IMHO, the only way to facilitate this is to remove the integration bottleneck. We can't be spending 2-4 days of the 2 week release period in an unstable integration state. My contention is that if people can deliver their completed tasks up to an integration branch themselves, the moment they are finished and they don't have to workaround collisions with someone else's code (that haven't been resolved already in the task branch) then we will have a more stable integration codeline, with more quantifiable, easily-excluded changesets when it comes time to release something.

Regards,