[p4] tracking 3rd party sources

[Robert Cowham]

> My understanding of her recommendation (please correct if 
> I've got some detail wrong) is as follows:
> 
> 1. Import pristine upstream source code into a separate 
> "import" codeline,
>    say //depot/IMPORT.
> 
> 2. Integrate from //depot/IMPORT into your development codeline.
> 
> 3. When a new version comes out, commit it into IMPORT, making the
>    necessary additions, deletions, and changes.  Then integrate the
>    new version into your development codeline again; this allows you
>    to benefit from Perforce's 3-way merge.
> 
> 
> So, as I said, I'm interested to learn if this is the common practice.

I would say it is definitely good practice to do this and widely followed.

> If so, do you put *all* 3rd party stuff into the same import codeline?
> Do you include 3rd party code used in locally-written build tools?
> 
> 
> We're having a bit of a debate about whether to put all 3rd 
> party stuff into the same import codeline or not.  We're 
> planning to have a few different "suites" of products, each 
> with its own release cycle.
> Therefore we're structuring our repository with a set of 
> codelines per suite; e.g. //depot/suiteA/MAIN, 
> //depot/suiteB/MAIN, etc.  Each suite will have several 
> products; e.g. //depot/suiteA/MAIN/prod1, etc.  The debate is 
> whether to have a global import stream (//depot/IMPORT), one 
> per suite (//depot/suiteA/IMPORT), or even one per product 
> (//depot/suiteA/prod1/IMPORT).  I'd appreciate thoughts from 
> the battle-scarred on these options.
> 
> There's also a debate about whether imports should be 
> reserved for 3rd party code that is linked with ours, as 
> opposed to 3rd party code used in locally-written build tools.
> 
> If your group has a better way of doing things, I'd 
> appreciate hearing about it.

It depends on how much and from whom you get stuff, and in what form.

It comes down to personal preference at some point, and is part of the
general practice of how you sturcture your repository and what naming
conventions you use.

If there is a fair amount of it, I think a /import/ or similar structure
works well. As to where exactly it comes in the scheme of things - see what
makes sense for you.

Apart from anything else you should think 2-5 years ahead (within reason),
and have a structure which scales well over such timescales. A generic
//depot/import or similar is a good idea, but other structures are fine as
long as they have a reasonable explanation.

Robert