[p4] Guidelines for codelines?

Greg Whitfield Greg.Whitfield at lightworkdesign.com
Fri Nov 21 01:22:12 PST 2008


I'll backup what Rick says - using development branches has been a huge
plus, and I could not imagine working effectively without them. Where
you have a team of programmers it is a massive help in preventing them
stomping all over each other and breaking the build. Mostly his approach
of merge-down/copy up works quite trivially. I have found it useful
occasionally to do per-changelist integrations but that is normally in
situations where code has been restructured in a  dev branch and you
want to ensure feature enhancements in mainline make their way up
properly. In this situation, "p4 interchanges" is really useful, and I
recommend you check it out (no pun intended!).

Chris's suggestion of a CGI script may not be needed if "p4
interchanges" does the job for you. I guess it depends on what specific
info you want in the reports.

Greg
~~~~

 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Chris Helck
Sent: 20 November 2008 22:26
To: Rick Macdonald; Matt Craighead
Cc: perforce-user at perforce.com
Subject: Re: [p4] Guidelines for codelines?

On a related note, I've been wondering whether some of this can be
avoided by generating reports. A CGI script could look at all branch
specs and list all unintegrated changes in the direction of the normal
flow (release -> main -> development) as well as reverse flow. This
report might help spot branches that are going to have integration
problems early on. Thoughts?
-Chris


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Rick Macdonald
Sent: Thursday, November 20, 2008 3:31 PM
To: Matt Craighead
Cc: perforce-user at perforce.com
Subject: Re: [p4] Guidelines for codelines?

Matt, I'm responding to this not to change _your_ mind, but just for
another viewpoint for the original poster.

Not using development branches seems a severe way to avoid mass
integrations. You can retain the benefit of having development branches
without mass integrations simply by making a list of all the changelists
and integrating them one at a time. Combine this with "Merge down - Copy
Up" and it is not as traumatic to the mainline as doing development
directly in the mainline can be.

Having said that, we have always "merged down - copied up" but in 10
years of Perforce use in our company I've never heard of anybody needing
to integrate one changelist at a time. I've seen several people here say
they do, and I think Laura suggests it in her book. A lot of it depends
on the scope of development tasks. Ours are typically relatively small
and don't take long to do.

I can't imagine not using branches. It's a big plus to have a different
codeline policy for my dev branch than for the parent (mainline or
whatever). I can checkpoint/backup changes to my dev branch even if they
don't compile. That gives me rollback, history and diff features. Other
programmers can sync and work with or test other people's branches.

Rick

Matt Craighead wrote:
> My personal recommendation is to avoid development branches.  I've 
> found development branches to be a lot more trouble than they're 
> worth.  One of the biggest problems is "mass integrates".  I've 
> written about this on my
> blog:
> http://www.conifersystems.com/2008/11/05/the-benefits-of-small-commits
> / http://www.conifersystems.com/2008/11/12/when-are-small-commits-bad/
>
> 'One common way people end up committing large changes is the dreaded 
> "mass integrate".  That is, you have two branches, and you want to 
> catch up the one branch with all the changes made to the other branch.

> In a mass integrate, rather than integrating each individual change 
> over by itself, you integrate all of the changes together in one big 
> commit.  Mass integrates may touch hundreds or thousands of files.'
>
> Also, in Perforce you can undo a bad change, but you can't 
> simultaneously roll back the integration history -- if you undo the 
> change, the integration history will be wrong.  This makes these
changes especially dangerous.
>
> I would say you are better off having all development take place in 
> the main branch.
>
> On Mon, Nov 17, 2008 at 4:45 PM, steve at vance.com <steve at vance.com>
wrote:
>
>   
>> The release codeline should only be for fixes to defects found in QA 
>> on the release. Fixes found in other releases that need to be ported 
>> to that release qualify through integration.
>>
>> Think of your use of development codelines (you're really talking 
>> multiple, not just one, right?) as ways to avoid risk to the ongoing 
>> releasability and productivity of your mainline. Some people only 
>> integrate to the mainline because the only want fully qualified and 
>> reviewed changes there and branches help them implement that process.
>>
>> Feature that may not be done before next release? Branch it. Project 
>> with significant architectural change? Branch it. Prototype or 
>> one-off development? Branch it. Want to be able to check in without 
>> necessarily following the code quality rules on main (with good 
>> justification, of course)? Branch it.
>>
>> Steve
>>
>> Original Message:
>> -----------------
>> From: Chris Helck Chris.Helck at us.icap.com
>> Date:   Mon, 17 Nov 2008 15:58:26 -0500
>>  To: perforce-user at perforce.com
>> Subject: [p4] Guidelines for codelines?
>>
>>
>> We are following the standard development, main, release model and 
>> I'm trying to create guidelines for our developers to help them 
>> figure out which codeline they should work on. My question is when 
>> can work be done directly on the main line? It seems to me the logic 
>> goes something like
>> this:
>>
>> 1. If the change is for a specific release and the release codeline 
>> exists then the change goes on the release codeline.
>> 2. If the change is an experiment, a large open ended change, or for 
>> an unscheduled release then it goes on a development codeline.
>> 3. Everything else can go on the main.
>>
>> This isn't very crisp and it's bound to be confusing. Can someone 
>> suggest a clearer statement?
>>
>> Also, I understand some people use the main only for integrations.
>> When/why is this recommended?
>>
>> Thanks,
>> C. Helck
>>
>> *********************************************************************
>> * This communication and all information (including, but not limited 
>> to,  market prices/levels and data) contained therein (the
>> "Information") is  for informational purposes only, is confidential, 
>> may be legally  privileged and is the intellectual property of ICAP 
>> plc and its affiliates
>>  ("ICAP") or third parties. No confidentiality or privilege is waived

>> or  lost by any mistransmission. The Information is not, and should 
>> not  be construed as, an offer, bid or solicitation in relation to 
>> any  financial instrument or as an official confirmation of any
transaction.
>>  The Information is not warranted, including, but not limited, as to

>> completeness, timeliness or accuracy and is subject to change without

>> notice. ICAP assumes no liability for use or misuse of the 
>> Information. All representations and warranties are expressly 
>> disclaimed. The Information does not necessarily reflect the views of

>> ICAP. Access to the Information by anyone else other than the 
>> recipient is unauthorized and any disclosure, copying, distribution 
>> or  any action taken or omitted to be taken in reliance on it is
prohibited.
>> If
>>  you receive this message in error, please immediately delete it and 
>> all  copies of it from your system, destroy any hard copies of it and

>> notify the sender.
>> *********************************************************************
>> *
>>
>> _______________________________________________
>> perforce-user mailing list  -  perforce-user at perforce.com 
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
>>
>>
>> --------------------------------------------------------------------
>> mail2web - Check your email from the web at 
>> http://link.mail2web.com/mail2web
>>
>>
>> _______________________________________________
>> perforce-user mailing list  -  perforce-user at perforce.com 
>> http://maillist.perforce.com/mailman/listinfo/perforce-user
>>
>>     
>
>
>
>   
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

**********************************************************************
This communication and all information (including, but not limited to,
market prices/levels and data) contained therein (the "Information") is
for informational purposes only, is confidential, may be legally
privileged and is the intellectual property of ICAP plc and its
affiliates
 ("ICAP") or third parties. No confidentiality or privilege is waived or
lost by any mistransmission. The Information is not, and should not  be
construed as, an offer, bid or solicitation in relation to any
financial instrument or as an official confirmation of any transaction.
 The Information is not warranted, including, but not limited, as to
completeness, timeliness or accuracy and is subject to change  without
notice. ICAP assumes no liability for use or misuse of the  Information.
All representations and warranties are expressly  disclaimed. The
Information does not necessarily reflect the views of  ICAP. Access to
the Information by anyone else other than the  recipient is unauthorized
and any disclosure, copying, distribution or  any action taken or
omitted to be taken in reliance on it is prohibited. If  you receive
this message in error, please immediately delete it and all  copies of
it from your system, destroy any hard copies of it and  notify the
sender.
**********************************************************************



_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user




More information about the perforce-user mailing list