[p4] Deployment files in Perforce or Maven?

[Slava Imeshev]

Marilyn,

--- "Betsill, Marilyn" <betsillm at TEOCO.com> wrote:

> We are planning a migration from cvs to Perforce and are restructuring
> our repository directories similar to your *not like this* scenario. We
> have several products that use both common in-house developed code and
> 3rd party tools.  
> 
> In your preferred structure, it appears that a copy of the 3rd party

A natural way to do this is to place 3rdparty to a codeline of 
your preference (a trunk would do) and than integ it to places
where it is needed. "Originating" code line should do it.

p4 integ //depot/product1/3rdparty/... //depot/product2/3rdparty/...

e.t.c. 

> tools would exist with each product:
> 
> //depot/product1/3rdparty
> //depot/product1/src
> //depot/product1/bin
> //depot/product2/3rdparty
> //depot/product2/src
> //depot/product2/bin
> //depot/product3/3rdparty
> //depot/product3/src
> //depot/product3/bin
> 
> Several //depot/.../3rdparty directories contain copies of the same
> files.


Perforce does not create a physical copy of an integed item 
until it is changed, so you shouldn't have copy/space concerns.


> What is your preferred codeline structure when 3rd party code is used by
> several different deliverable products?

That is what I have outlined above. "Shared" codebases are bad, whether 
source or binary. To illustrate the problem, consider the "wrong"
structure

//depot/3drparty
//depot/product_v1
//depot/product_v2

Your depot view will likely look like the following:

//depot/3drparty/... //my_workspace/3rdparty/...
//depot/product_v1/... //my_workspace/product_1/...

Consider also that there is a binary dependence of an 
Other Vendor Software of version 1.7 in in form of a jar file

//depot/3dparty/other_vendor/client_lib.jar.

Now, team working on product_2 decides to update Other Vendor's 
client_lib to version 2.1. Change is made their code builds fine, 
they check it in and oops, the product_v1 that other team works 
on stops building, tests begin failing (or, worse, blows up in 
production) because new 2.1 is not compatible with 1.7. 
Consequences are obvious.

Whether this will happen depend on a lots of thing that it should
not depend on, such as, if there is an automated infrastructure
to identify build and test breakage, how rigorous the QA process
is, how well "others" aware (!) of you depending on shared code,
if there is a policy prohibiting updates to 3rdparty and allowing 
adds only, if there is a dedicated “3rdparty maintainer” and on and on.

I have given just a sample list of approaches one may try to 
keep codebase stable with shared 3rdparties. Nothing of this 
should and will matter if a codeline is selfcontained as I
recommended.

Hope this helps.

Regards,

Slava Imeshev
vimeshev at viewtier.com
www.viewtier.com

> 
> Thanks,
> 
> Marilyn
> 
> 
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Slava Imeshev
> Sent: Wednesday, January 10, 2007 2:28 AM
> To: perforce-user at perforce.com
> Subject: Re: [p4] Deployment files in Perforce or Maven?
> 
> That's an interesting point. 
>  
> Being in software build automation and management for awhile 
> I strongly suggest keeping *all* product dependencies in Perforce. 
>  
> The main problem with the external dependency repositories is that
> they introduce an additional maintenance point that makes reproducing
> builds practically impossible
> 
> The only realistic way to reproduce a build that has ever gone outside 
> of a build box while an external dependency repository is in picture is
> to 
> make snapshot  backups of that repository in sync with a state of the
> codeline 
> at the build time. Bullet and foolproof implementations of such process 
> remain to be seen. External dependency repositories make 
> multi-codeline product development plain dangerous.
>  
> One may argue that adoption of tools like maven grows but if you 
> look closer it is mainly in open source area where a [scary] practice
> of "releasing from the tip" is common, and past states are not important
> 
> because of no need to support past releases, nor reproducible.
>  
> Comparing to the above Perforce capabilities such as speed and ease 
> of  use, and practically free disk storage and network bandwidth,
> storing and managing dependencies in Perforce depots is simple, 
> transparent and *very* robust. I strongly recommend this.
>  
> I'd guess there world be other opinions. Mine one has grown from
> multiple client engagements and painful customers' experience. The 
> recent one is just a month old when we had to untangle mess created 
> by use of a "local repository". A customer discovered that they haven't 
> had a clean build for about 6 months after the maven "repository"
> "glitched".
> "Latest" "clean" build was picking up a "snapshot" dependence 
> that was gone long ago from the code.
>  
> As we touched this topic, I also recommend keeping the dependencies
> along with codeline, not in a separate "dependencies" codeline, i.e.
> a well-organized codeline IMHO should look like:
>  
> //depot/product_version_1/3rdparty
> //depot/product_version_1/src
> //depot/product_version_1/bin
> //depot/product/3rdparty
> //depot/product/src
> //depot/product/bin
>  
> and *not* like this:
>  
> //depot/3rdparty
> //depot/product_version_1/src
> //depot/product_version_1/bin
> //depot/product/src
> //depot/product/bin
>  
> Just my 2c...
>  
> Regards,
>  
> Slava Imeshev
> vimeshev at viewtier.com
> www.viewtier.com