[p4] Perforce coping skills for CVS users - Chuck Karish - com.perforce.perforce-user

9 messages in com.perforce.perforce-user[p4] Perforce coping skills for CVS u...

From	Sent On	Attachments
Andy Turk	12 Mar 2002 14:44
Ken Wilson	12 Mar 2002 15:15
Stephen Vance	12 Mar 2002 15:24
Jeffrey Jensen	12 Mar 2002 15:30
Maurice Meyer	12 Mar 2002 16:25
Stephen Vance	12 Mar 2002 16:30
Gregg G. Wonderly	12 Mar 2002 20:52
Maurice Meyer	13 Mar 2002 15:46
Chuck Karish	14 Mar 2002 07:34

Subject:	[p4] Perforce coping skills for CVS users
From:	Chuck Karish (kar...@well.com)
Date:	03/14/2002 07:34:15 AM
List:	com.perforce.perforce-user

At 03:47 PM 3/13/2002 -0800, Maurice Meyer wrote:

I just don't like to use branching where it doesn't need to be used.

Simple rule: Branch when it's necessary to develop a code line under two conflicting policies.

Corollary: For a branch that's shared and supported, don't branch until it's absolutely necessary. When it is necessary, branch immediately.

If you branch too soon you'll waste a lot of time merging changes that should have been made before the branch. If you branch too late there'll be a flood of changes that developers hadn't been able to check in, and development will have been obstructed while those changes couldn't be shared among the team members.

I don't mean to say branching is not good - it's great. But, I have seen it overused. For example at a former company there was talk of a mandated branch for every change. Every single one file, one line change. That's excessive and over-burdens the development effort.

I've seen that technique used as part of a primitive version control system. To support parallel development, share the whole code tree. Changes that apply to both branches are just checked in. When a change applies only to one branch the individual file is branched. A manifest is maintained by hand to keep track of which version of each file goes into he build on each branch.

Be thankful that you have a tool that makes this unnecessary.

I just try to avoid making private branches if I can. There is a lot you can do in a client without having to make a branch.

When making a branch is the easiest way for a developer to check in changes on an ongoing project that would otherwise destabilize the main code line, I encourage branching. Branches are easy and cheap under Perforce. As long as the developer is maintaining it, I don't see a down side to branching on need.

The original question was about setting up ways to use multiple clients to try different methods of implementing a change. In that case, I think it'd be easier to not branch and just create a copy client script.

If the developer wants to check in changes it's necessary to make at least a partial branch (or copies of individual files). For someone who's moderately proficient with Perforce it's easier and less error-prone to just make a branch than to manage one-off changes to the code tree. The people I support are a lot more proficient with the code management system than they are with shell scripts.

Creating a bunch of trys at the same change implies comitting one and deleting the others. Clients are easier to delete than branches for the most part (especially if you don't have super privs).

If you own a personal development branch you can delete it. It takes a while, and can cause a significant chunk of the depot to be locked during the delete.