[p4] tracking 3rd party sources

[Andy Finkenstadt]

Robert Cowham wrote:
>> What is working for us to accept varied third-party source 
>> and object code drops is to use a configuration like:
>>
>>   //depot/vendor/$VENDOR_NAME/$PRODUCT_NAME/$PRODUCT_VERSION/...
>>     
>
> This naming convention is good and clear.
>
>   
Thanks... I think it came straight from Laura's PRACTICAL PERFORCE book.

> One extra wrinkle worth considering is:
>
> Import as a single changelist into say
> //depot/vendor/$VENDOR_NAME/$PRODUCT_NAME/import and then if you want to be
> very clear about which version you are using internally, branch that to
> //depot/vendor/$VENDOR_NAME/$PRODUCT_NAME/$PRODUCT_VERSION
>
> (It is perfectly reasonable just to use say a changelist or dynamic label to
> record what the changelists corresponded to, but sometimes it is worth
> having the explicit version number in the Revision Graph history, i.e. an
> extra branch).
>
> And then integrate from there to your internal (possibly customised)
> version.
>
> The advantage of this is that you are only storing the differences (between
> revisions) in the import branch, and the version branch is just a standard
> perforce lazy copy. The other method will end up adding a complete copy of
> all the files (many of which won't have changed), and over time this may
> start to mount up a bit.
>
> With the new common ancestor detection, the fact that you integrate from
> v1.2 and then v1.3 which have a common parent in import, is not going to be
> a problem.
>   

I'm not sure I understand why the other method ends up with complete 
copies.  I think I left off the vendor drop pattern from my previous 
email (which hasn't shown up yet on the list), where I explicitly

p4 integ --v t //depot/vendor/../old_version/... 
//depot/vendor/../new_version/...
p4 submit
extract archive into new_version
p4 diff -se ... | etc
p4 diff -sd ... | etc
find new_files | etc
p4 submit

which I think does the same lazy copies, no? I'm still relatively new as 
the /de facto/ perforce admin for our company, but it seems like if I'm 
wrong about that, then I'm wrong about a lot of things.  *sigh*

--andy