[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