[p4] moving projects from one depot to another

[Greg Whitfield]

Can I just correct the statement on licensing that Qazwart makes. 

Having multiple servers does *not* mean you need more licenses. Perforce is
licensed on a per-user basis, irrespective of how many servers you have. You
just need to contact Perforce to arrange duplicate server licenses, and sign
something that says you are not using the duplicate license to get more
users that you paid for.

Before doing anything you should do some profiling - as Qazwart says, simply
moving depots around will probably not affect performance. The standard
things to look at outside of memory/cpu/disk/network things are the scope of
all the user views. If your current depot structure means that all your
users have to have the entire Perforce depot mapped in, then perhaps a
restructure would allow you to narrow the client views somewhat. But I'm not
convinced this would make a massive difference - dependent on user base,
number of files etc.

I would turn on server logging and save the log each day for a week or so.
Then use something like P4GLA to examine what is really going on in the
server. This will help determine things like wide views, whether users are
force syncing all the time, how long operations take etc. It will also show
you the number of simultaneous operations from which you can determine if
database locks are contributing to the problems.

Restructuring using branching is fine, but why worry about hiding the
original location? Simply lock the old depots against modification.

If you really insist on changing your depot so it looked like you never had
the old structure, then checkpoint surgery is probably your best bet. But
this is potentially dangerous and so ensure you do *lots* of testing and
dry-runs first.

Greg
~~~~

 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Qazwart
Sent: 22 February 2007 02:44
To: Tyler Hopaluk
Cc: perforce-user at perforce.com
Subject: Re: [p4] moving projects from one depot to another

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
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user