[p4] storing builds (was Nant Build Question)

[Weintraub, David]

Not all hope is lost...
 
As Jeff suggests, use two separate P4 servers. One, p4-dev will be for
development, the second, p4-prod, will be for the end users. On p4-prod,
create a remote depot that maps to the PROD branch of the depot on
p4-dev. Now, users on p4-dev can see the integrations, history, etc. of
what is in production, but users on p4-prod won't have access to any
information that is on p4-dev other than what they see in the remote
depot.
 


________________________________

	From: Stephen Vance [mailto:steve at vance.com] 
	Sent: Wednesday, September 20, 2006 1:47 PM
	To: Jeff A. Bowles
	Cc: Weintraub, David; Jesus de Santos Garcia; Perforce Users
	Subject: Re: [p4] storing builds (was Nant Build Question)
	
	
	Jeff's suggestion has merit from a management point of view. A
weakness of that approach is that you lose the relationship between the
build and the source whereas you can relate them through jobs,
integration records, labels, changelists, etc. with tighter affinity
when they're on the same server.
	
	Steve
	
	Jeff A. Bowles wrote: 

		Honestly, I think I would do it as a separate Perforce
server with its
		own database, that you "authenticate to" separately.
		
		Just check in the derived things as
//releases/whatever/... (make a new depot)
		and you can use labels or integrates or 'p4 sync' to put
copies where you want.
		
		Better, if you ever worry about clients/customers having
access to the source
		code, that's "in a more secure place". (I.e., we don't
have to share
		our development
		information.)
		
		Even more, since cleanup (if you ever have real
disk-space issues) might be
		easier and less bothersome if it's a server that is
separate from your
		development
		source.
		
		Normal development use can pull it over from the other
server in about three
		different ways. (Just be consistent: derived things get
checked into
		the "releases"
		server.)
		
		My $0.02.
		
		   -Jeff Bowles
		   Perforce Consulting Partner
		
		On 9/20/06, Weintraub, David
<david.weintraub at bofasecurities.com>
<mailto:david.weintraub at bofasecurities.com>  wrote:
		  

			Storing built objects is a controversy in CM
management.
			
			One side says "Why store what you can rebuild?
It wastes room, cuts down
			performance, and causes management headaches.
Besides, storing built
			objects is a sign of a lazy CM process where you
doubt that you can
			rebuild the same way over and over again. The
Subversion development
			team takes this view and is one of the reasons
that Subversion doesn't
			contain an "obsolete" command. There's no need
for one if you're simply
			storing text source files.
			
			The other side says "Why rebuild when you can
store?". They say that it
			can save developers time and effort to have
pre-built objects. And, by
			storing your built objects in your version
control system, you're
			dealing with administrative issues such as
backup and retention policy.
			
			I am in the second camp. Storing the output of
your nightly builds gives
			everyone a single place to get an official copy.
There is no controversy
			whether that binary came from you or from
someone else. Plus, you can
			use Perforce as your deployment mechanism too.
The problem is that you
			need an active program to obsolete versions that
are no longer needed.
			Otherwise, you're simply going to overwhelm your
depot area with
			binaries that no one needs.
			
			In ClearCase, this was pretty simple since
ClearCase would (by default)
			not remove versions that had a label attached to
them. That meant we
			could remove obsolete labels, then do a
"cleartool rmver" of everything
			older than 2 weeks. And, we knew full well that
our production binaries
			would not get deleted accidentally. You have to
do a bit more legwork in
			Perforce to make sure you don't delete a binary
that you need.
			
			I lean towards storing binaries on branches
depending upon the
			environment. Daily builds on one branch,
Released to QA on another, and
			Production on a third. Deleting a daily build
won't accidentally remove
			a binary that your customers are currently
using.
			
			-----Original Message-----
			From: perforce-user-bounces at perforce.com
			[mailto:perforce-user-bounces at perforce.com] On
Behalf Of Jesus de Santos
			Garcia
			Sent: Wednesday, September 20, 2006 4:38 AM
			To: perforce-user at perforce.com
			Subject: [p4] storing builds (was Nant Build
Question)
			
			Hi,
			
			I'd like to know if it is usual to store the
output of a night build in
			a perforce server.
			
			We currently have daily incremental builds and
nightly full builds using
			CruiseControl.net and nant but we are storing
there in a shared folder
			for our clients (internal teams). Each build is
aprox 2GB.
			Our clients later, store the proper build in
their perforce server...
			(as they do with other 3rdparty libraries)
			
			We are thinking in the idea of storing our build
in perforce so that
			clients can integrate from our respository.
			
			Any suggestions?
			
			Thanks and sorry for not being able to answer
your specific question.
			
			    

				Anyone using Nant?
				
				We copy built .NET assemblies into an
assembly folder and check that
				into Perforce. However, the list of the
assemblies to check in may
				change from time to time, so I need to
add new assemblies, delete
				assemblies that we no longer build, and
submit any new assemblies that
				      

				we change.
				
				
				      

			_______________________________________________
			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