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

jab jab at pobox.com
Tue Mar 8 07:36:14 PST 2005


At 2005-03-07 17:35:50+0000, "Jay Glanville" writes:
> 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."

My initial response to Jay wasn't cc'ed to the list. This one is.

My initial thoughts were, "no one's a perfect typist" and that anyone 
who retypes
a change ("cut/paste" is a form of retyping) when the tools do it 
directly, is inviting
trouble.

I believe that I'd seriously evaluate my "p4 protect" table and trigger 
setup, if I had
a user who was hostile to the notion of "key in the work in one place, 
integrate it
to propagate to others".   More specifically, I'd have a trigger that 
disallowed checkins
to multiple trees at the same time, and would work with the developers 
to try to
have a script that propagates "easy" changes from a child codeline to 
its parent.
If that wasn't sufficient, I'd start reworking permissions to enforce 
(as opposed to "suggest")
policy strongly.

	-Jeff Bowles

ps. It's worth remarking to this .... uhhh... guy, that "p4 resolve -n" 
followed by 20 seconds
of think-time and then "p4 resolve -am", is going to be a very good 
thing to know about.




More information about the perforce-user mailing list