[p4] why should I restrict a changelist to a branch?

steve at vance.com steve at vance.com
Mon Mar 7 14:32:08 PST 2005

Let's tackle the "why integrate" question first.

o  Integration means you don't have to do the change twice.
o  It means that even in trivial cases, change propogation is handled in a
consistent manner.
o  With the -i flag, branching history is shown in the target codeline as
well, including the history of contributing merges.
o  With integration you have a mechanism to formally choose whether to
propogate a change or not in a manner that controls whether you will ever
have to re-visit the change for merge purposes (-ay/-at). While you could
achive the choice part by checking in a zero-delta revision on the branch,
you would still have to revisit the merge if you were to merge between the

Speaking more to the practice of one branch per changelist,

o It's a matter of policy and roles whether the same person fixes on both
branches. That separation of roles suggests that even when the user id is
the same the role submitting on the two branches is different, such as that
of developer and QA. It then becomes a matter of accountability.
o  If it seemed reasonable for the developer to put the change in a single
changelist for his two branches, why didn't he do it for all branches in
the system? I'm assuming here that there were other branches he could have
also submitted it to.
o  More formally speaking, a branch and a codeline represent a variant of
the system under development, which should have its own unique change
history. Integration represents the variant relationship, while changing it
independently on each branch, even if in the same changelist, treats it as
two separate changes that are possibly logically related.

Overall, it's a matter of "just because you can doesn't mean you should."
The issues are those of managing a larger scale code base rather than the
convenience of a single developer.


Original Message:
From: Jay Glanville Jay.Glanville at naturalconvergence.com
Date: Mon, 7 Mar 2005 12:35:50 -0500
To: perforce-user at perforce.com
Subject: [p4] "why should I restrict a changelist to a branch?"

Hello all.

I need some help (in so many ways, but for now, lets focus on P4 help).
I need a good argument for a situation.

Just the other day, I noticed that co-worker submitted a changelist that
modified the same file in two different branches.  I recommended to him
that it probably would be better if he limited a changelist to a single
branch.  To which, he replied, "Why?  Both versions of the file were
modified for the same reason (a bug)."

My counter argument was, "to keep the two branches in sync.  By making
the change in one branch, and then integrating it into the other branch
allows us to see that delta A has been propagated to the other branch."

His counter to my counter was, "So what?  Once they branched, they now
have separate lives.  If I want to apply a single change to both
versions, I'll do it in a single changelist.  Besides, what does an
integrate actually mean?  Does it mean that the branches are
synchronized?  What does it mean when I've only propagated some changes
and not all?  Performing 'p4 integrate' doesn't actually give me

And that's where I failed:  I couldn't think of a good argument as to
why he should limit a changelist to a single branch.

Let me ask, oh wise and glorious P4 gurus (a little flattery never hurts
;-) ), what arguments would you give to encourage your users to limit
their changelists to a single branch?  Or would you?  Is there anything
wrong with what my co-worker has done?

I apologize as this is a slight off-topic request (it doesn't directly
apply to P4, but is more a general source control management
philosophical question).



Jay Glanville
Application Software Designer
Natural Convergence

Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
Learn more: http://www.perforce.com/conf 

perforce-user mailing list  -  perforce-user at perforce.com

mail2web - Check your email from the web at
http://mail2web.com/ .

More information about the perforce-user mailing list