[p4] storing builds (was Nant Build Question)

Jesus de Santos Garcia jsantos at pyrostudios.com
Wed Sep 20 10:17:40 PDT 2006


We actually follow this pipeline. Imagine two teams (A and B), A is 
releasing everyday to team B.

1. TeamA works in its own perforce server. TeamB also works in its own 
perforce server.

2. Everynight, a BuildMachine in the team A, gets all the source from 
the depot and build everything from scratch. The result is a 3GB SDK 
that is stored in a shared folder.

3. In the morning, the integrator of Team B, get the SDK from the shared 
folder using rsync (so although every file is rebuilt, only really 
changes are downloaded).

4. The integrator of Team B, store the SDK in the perforce of TeamB (in 
a folder without history, +S flag I think)

5. Everybody in Team B has a new fresh SDK.

Do you think we should avoid the rsync process and store the 3Gb in 
perforce every night? Will perforce be smart enough to only download 
changed files (although all the files are new) like rsync?
With the shared folder, rotating (to delete old versions) is really 
easy. Using perforce for this task seem to be more dificult.

Thans for the info.

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


More information about the perforce-user mailing list