[p4] moving projects from one depot to another

[Qazwart]

Having separate depots won't solve your performance issues. Unlike  
ClearCase where each VOB (ClearCase's equivalent of a depot) has its  
own database, all the depots on a single server share the same  
database. Splitting up the depots really won't help performance. Your  
database and source file archive would still be the exact same size  
after the reorg.

What you need to do is find out why you are having poor performance  
issues. Is it related to the database? When was the last time you  
rebuilt the database via a checkpoint file? Maybe deleting some  
obsolete Perforce client views and rebuilding the database would help  
since that will reduce the size of the have.db. Or, is the  
performance problem related to network constraints? Are there a lot  
of Perforce server processes swapping out of memory? Maybe adding  
more memory help. Talk to Perforce support. Perforce support can help  
you figure out your you're experiencing these performance problems.

If you still want to restructure your depots, again, call Perforce  
support. The easiest way is to reorganize the depots is to have  
Perforce take your checkpoint file and manipulate it, and have you  
rebuild your database. Again, depot restructuring won't help your  
performance issues. The only way to put less stress on the server is  
to split the depot into multiple Perforce server instances. That  
would then mean needing more licenses (since licenses are per user  
per Perforce server instance), and it would be more difficult to work  
with files that are spread across multiple depots.

However, considering Google uses a single Perforce instance to manage  
their entire company, I doubt that splitting the depots into separate  
server instances would be necessary. The idea is to find out why  
you're getting the poor performance and to take care of that  
particular issue.

On Feb 21, 2007, at 8:55 PM, Tyler Hopaluk wrote:

> I inherited at situation that I don't know how to handle.
>
>
>
> Do to poor perforce management we have several depots that all  
> contain different projects. What we have been directed to do is  
> consolidate all the various projects in different depots to one  
> depot for each project type. For example:
>
>
>
>
>
> Current organization:
>
>
>
> Existing Depot 1: proj_type_A_1
>
>                           proj_type_B_1
>
>
>
> Existing Depot 2: proj_type_B_2
>
>                           proj_type_C_1
>
>
>
> Existing Depot 3: proj_type_A_2
>
>                           proj_type_C_2
>
>
>
>
>
> Required organization:
>
>
>
> New Depot for A types: proj_type_A_1
>
>                                    proj_type_A_2
>
>
>
> New Depot for B types: proj_type_B_1
>
>                                    proj_type_B_2
>
>
>
> New Depot for C types: proj_type_C_1
>
>                                    proj_type_C_2
>
>
>
>
>
> The problem is that the depots will have different names then the  
> existing and the old depots will need to be deleted/removed/hidden  
> from depot listing of the users. Doing an integrate will  
> effectively move the current revision of the files to the new  
> depots but the history will still point to the old paths on old  
> depots and once the old depots are gone, so is that file history.
>
>
>
> The only possible solutions that come to mind is either find some  
> way to hide the old empty depots from the users but still allow  
> them to access the file history they contain, generate some  
> elaborate script that will start at the head of each file and do a  
> get revision,copy the file to the new location, check in, get next  
> revision, copy, check in, etc. Or lastly, loose the file history  
> and start from scratch.
>
>
>
> So far I don't believe perforce permissions allow hiding of the  
> listing of the old depots and still allow users to access the old  
> file revisions from them. The scripting method is also very  
> undesirable do to the large amounts of files and many revisions,  
> plus the script way will cause the date/time information to be lost  
> as well as the original user who checked in the file. And loosing  
> the history defeats the point of using perforce in the first place.
>
>
>
> It would be great if there was some admin tool that could pull a  
> file and all its revisions out of a depot and move it to another  
> depot.
>
>
>
> Any ideas on how to handle this problem?
>
>
>
> Tyler
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user