Jump to content
  • Advertisement
Sign in to follow this  
tragic

Organization for Perforce

This topic is 830 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am getting started with perforce and I was wondering what everyone does for their server organization. Do you create depot's for each project? Or simply use folders under one big depot. Separate depot for assets? (Or engine, tools, etc.)

 

This ultimately a subjective question but I am horrible at organization so any examples or advice is appreciated.

Share this post


Link to post
Share on other sites
Advertisement

I've seen slightly different variations at different companies.  Also, the way P4 organized things has somewhat changed over the decades.

 

 

Generally there is a depot per project.  

 

Then underneath there is a main development line and private development lines.  Perforce calls these "streams". You fork and branch between these frequently as you develop. From my experiences it is good to have one private sandbox per developer.  You might also have another for releases and special snapshots, or whatever else you decide on.

 

Inside the stream projects get broken down by types of assets. Source code assets, audio assets, image assets, model assets. This allows individual groups to be selective about what they pull down. Programmers can get source code. Audio techs can work with the audio assets. Artists get images. Modelers get models.  Etc.  Studios I've worked have tended to also have directories for external products like compilers and external libraries because it is important that we can pull down a specific build and re-create it.  If we pulled down source but had a compiler that was newer or older than expected we cannot re-create that build. Same if we needed to pull down version 2.37.11 of an external library, we may not be able to find 2.37.11 months or years later unless we store it in the repository.

 

So let's say you've put together projects for a few years, you might have:

? Project name
|? ML or Mainline
|?? Source
| ?? Audio
| |? Graphics
| |? Physics
| |? Networking
| |? Assorted other directories
| |? Simulator
| ? Assets
| |? {assorted directories and files}
...
| ? External Dependencies
| |? {assorted directories and files }
...
|? SB.frob (sandbox 'stream' for my own branches, I integrate back and forth between ML)
||? Source
|||? Audio
...
|? SB.tragic (sandbox 'stream' for your own branches, you integrate back and forth between ML)
||? Source
|||? Audio
...
|? RL or Release Line
||? Source
|||? Audio
...
 

? Project #2 name |? Mainline or ML |?? Source ...

 

I've seen quite a few slight variations, but this general pattern seems to work well for most of the organizations I've worked at.

Share this post


Link to post
Share on other sites

I've seen slightly different variations at different companies.  Also, the way P4 organized things has somewhat changed over the decades.

 

 

Generally there is a depot per project.  

 

Then underneath there is a main development line and private development lines.  Perforce calls these "streams". You fork and branch between these frequently as you develop. From my experiences it is good to have one private sandbox per developer.  You might also have another for releases and special snapshots, or whatever else you decide on.

 

Inside the stream projects get broken down by types of assets. Source code assets, audio assets, image assets, model assets. This allows individual groups to be selective about what they pull down. Programmers can get source code. Audio techs can work with the audio assets. Artists get images. Modelers get models.  Etc.  Studios I've worked have tended to also have directories for external products like compilers and external libraries because it is important that we can pull down a specific build and re-create it.  If we pulled down source but had a compiler that was newer or older than expected we cannot re-create that build. Same if we needed to pull down version 2.37.11 of an external library, we may not be able to find 2.37.11 months or years later unless we store it in the repository.

 

So let's say you've put together projects for a few years, you might have:

 

-snip

 

I've seen quite a few slight variations, but this general pattern seems to work well for most of the organizations I've worked at.

It sounds like it works very much like git with streams.

 

Makes sense. Would you reuse assets between projects simply by copying them between the depot's?

 

I'll probably give this a go but is it difficult to restructure a depot midway through development if something isn't working out?

Share this post


Link to post
Share on other sites

It sounds like it works very much like git with streams.


Yes, it is a fairly common pattern in modern version control.

If you somehow prefer working with git you can configure a P4 client that works like a git repo. The commands are basically "git p4 clone", "git p4 sync", "git p4 submit", etc. 

 

Would you reuse assets between projects simply by copying them between the depot's?

I would make a copy and submit them as though they were fresh, but you probably could do something more complex as a proper fork.

 

is it difficult to restructure a depot midway through development?

Depends on how much you care about preserving the historical data.

 

Generally people I work with will just move the files locally, then hit reconcile in P4.  It will mark the old files for deletion and the new files for addition. This breaks the link for file history, but that usually isn't a problem. If someone needs to go digging through histories, when they go to revision 1 of the file the checkin notes say "move the files around", they will see the files deleted and the files added.  They may need to do a bit to find the default-hidden deleted files, but the histories are still available.

Share this post


Link to post
Share on other sites

 

It sounds like it works very much like git with streams.


Yes, it is a fairly common pattern in modern version control.

If you somehow prefer working with git you can configure a P4 client that works like a git repo. The commands are basically "git p4 clone", "git p4 sync", "git p4 submit", etc. 

 

 

 

Would you reuse assets between projects simply by copying them between the depot's?

I would make a copy and submit them as though they were fresh, but you probably could do something more complex as a proper fork.

 

 

 

is it difficult to restructure a depot midway through development?

Depends on how much you care about preserving the historical data.

 

Generally people I work with will just move the files locally, then hit reconcile in P4.  It will mark the old files for deletion and the new files for addition. This breaks the link for file history, but that usually isn't a problem. If someone needs to go digging through histories, when they go to revision 1 of the file the checkin notes say "move the files around", they will see the files deleted and the files added.  They may need to do a bit to find the default-hidden deleted files, but the histories are still available.

 

Okay cool. Thanks for your help frob. 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!