[p4] Guidelines for codelines?

Jeff A. Bowles jab at pobox.com
Thu Nov 20 12:10:14 PST 2008


So many of these points are good, but make an assumption I want to point out
explicitly:

   "How many of these decisions and strategies are decided because the
individual developers aren't sophisticated users?"

It isn't meant to be a slam at the casual Perforce user. (I can certainly
understand with someone who says, "I was hired to design some stuff in C#,
not to run your Perforce server.")
I tend to give advice, when teaching Perforce classes, such as, "make the
emergency patch in the codeline that supports the developent of that change
the quickest. Then integrate / merge to the other lines." (A one-line change
'here' is a whole lot easier to work with, than a 100001-line change 'there'
that is then back-integrated into the release line.)

If every developer who was doing work, understood VERY WELL the integration
process and merge tools, would it be that problematic to develop in main?
or in a dev codeline with back-integrates to main at every change or at
scheduled times?  I think it'd be okay either way, if you are fiercely
consistent with whatever approach you use.

------

Every possible answer you see in this thread is, in a way, a "right" answer
-- it depends on the dynamics you have with your developers and on the
composition of the entire engineering staff you're working with.    The
"right" answer for a group of six might be the "absolutely stupidest" answer
for a group of sixty, or six hundred, or six thousand. (Example: I remember
putting in a trigger that required bug-numbers in checkin descriptions and
being hailed as a savior by a development group. At my next job, the exact
same trigger caused a mild revolution within 12 hours and I had to remove
it.)

Your mileage may vary. Some shrinkage might occur during shipping. Use only
as directed. Do not write in this space. Filmed before a live audience.

    -Jeff Bowles


On Thu, Nov 20, 2008 at 11:34 AM, Looney, James B <
james.b.looney at ulalaunch.com> wrote:

> I'd disagree with developing in the main codeline.  My opinion follows with
> what Steve said.  With more than one developer at a time, you'll likely get
> into a mess where you step all over each other (such as when trying to
> compile).
>
> Yes, mass integrates can be confusing and misleading at times, but remember
> you can always make your development codelines as fine grained as you like.
>  We have some software in production.  It has several releases, sometimes
> bug fixes are required, and sometimes new features are added.  We create a
> new codeline for each bug fix and new feature.  Later on, when deciding what
> fixes/features are wanted in the next release, we integrate the changes from
> each of the appropriate development codelines to the mainline.  From the
> mainline, we then create a release.
>
> The above does require that mainline changes be tightly controlled.  So we
> have one guy who performs the appropriate integrations.  It works well for
> us.  Also, codelines are pretty cheap to create since it's mostly just a
> database entry.  As I understand it, files aren't created in the repository
> until changes are committed.
>
> We also have development on software products that aren't in production.
>  For those products, we usually have one development codeline per developer.
>  With that sort of software development, we generally aren't as concerned
> with mass integrations since most of what the developers create is probably
> useful for the overall product.  But we definitely communicate, and strongly
> suggest to the developers to integrate back to mainline on a fairly frequent
> basis to help avoid getting confused.
>
> That's my 2 cents,
> -JB
>
> > -----Original Message-----
> > From: perforce-user-bounces at perforce.com
>  > [mailto:perforce-user-bounces at perforce.com] On Behalf Of Matt
> > Craighead
> > Sent: Thursday, November 20, 2008 11:49 AM
> > To: steve at vance.com
> > Cc: perforce-user at perforce.com
> > Subject: Re: [p4] Guidelines for codelines?
> >
> > 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
> > >
> >
> >
> >
> > --
> > Matt Craighead
> > Founder/CEO, Conifer Systems LLC
> > http://www.conifersystems.com
> > 512-772-1834
> > _______________________________________________
> > 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
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com



More information about the perforce-user mailing list