[p4] p4DTI in Perl ?

Robert Cowham robert at vaccaperna.co.uk
Wed Jun 28 04:34:37 PDT 2006


> On 6/26/06, Weintraub, David 
> <david.weintraub at bofasecurities.com> wrote:
> > Although merging two separate Perforce server instances is not an 
> > everyday task, it is common enough and important enough 
> that you would 
> > want a robust utility to carry out this function. Companies 
> reorganize 
> > themselves everyday, and that includes reorganizing how they handle 
> > their source control.  Company "A" buys out Company "B", 
> and wants to 
> > put Company "B's" source on their source control server. A 
> company had 
> > dozens of Perforce server instances, upgrades their network, gets a 
> > more powerful server, and decides to consolidate their Perforce 
> > servers. One group which is using Perforce moves to another 
> building 
> > or city, and wants to move their source from one Perforce server to 
> > another. Or maybe the group doesn't physically move, but their 
> > organization moves to a new department and now that group wants to 
> > move their source to the Perforce server used by that new 
> department.
> 
> Do you know of a company that does this?  The ones I've 
> worked for are serious about preserving their source 
> databases as mirrors of their development history.  Inserting 
> changes retrospectively that were done at another company 
> doesn't fit this purpose very well.
> 
> Consolidating onto more powerful hardware is easy: you run 
> multiple server instances, each listening on a different port.
> 
> Combining databases is hard because you have to either 
> renumber the changelists for both databases or sacrifice the 
> changelist numbes and date and time information for one of 
> them.  A more commonly used strategy is to import a small 
> amount of history.  Sometimes the redundant server is kept 
> running for reference.

Couldn't have said it better myself! 

This is definitely my inclination. Of course YMMV.

Robert


More information about the perforce-user mailing list