[p4] storing builds (was Nant Build Question)

[Jeff A. Bowles]

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> 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
>
>


-- 
---
Jeff Bowles - jab at piccoloeng.com