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

Grills, Jeff jgrills at soe.sony.com
Mon Mar 7 18:45:16 PST 2005


I think whether this is reasonable or not depends upon your workflow.
If you make separate branches for different versions of your product,
then making the same change to multiple branches by editing rather than
integrating may be a reasonable thing to do.  I personally still believe
that the fix should be integrated and submitted in multiple changelists,
but I can see that not everyone would agree.  At very least, I believe
that they should be in separate changelists even if the user is just
editing the file and manually replicating the change.

You can enforce single-branch submissions with a p4 pre-submit trigger
that checks to make sure that the files being submitted follow that
rule.

In our development, we have a more "rolling" development process, where
we basically have the following branches:

	sandbox[1-n] <-> current <-> test <-> live

Development primarily happens in N number of sandboxes, and when the
sandbox is ready, it gets promoted to current.  When all appropriate
sandboxes for a release are all in current, we integrate all of current
to test.  Once QA passes the version in test, we integrate that to live.
So for us, eventually every change makes its way into current (and all
the branches, for that matter).  We couldn't possibly keep up with all
the changes unless perforce was tracking the revisions integrated
between the branches.  Developers have to integrate between the branches
rather than replicating their changes to make sure that we have
everything integrated.  We actually run daily reports to find unexpected
unintegrated files and send email to the appropriate users (for
instance, emergency changes in live should be reverse integrated to test
immediately).

j

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Jay Glanville
Sent: Monday, March 07, 2005 11:36 AM
To: Perforce Users Mailing List
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
anything."

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).

Thanks.

JDG

 
---
Jay Glanville
Application Software Designer
Natural Convergence




More information about the perforce-user mailing list