Full Video Transcript
Hi, my name is Ryan Maffesoli, and I'm a solutions engineer here at Perforce.
In this series, we're going to go through some of the more day to day or basic admin operations you'll use when administering your Helix Core server. For that, I'm going to be using the P4 Admin tool, which is available on Windows, Mac, and Linux. However, if you are more comfortable in the command line, you can feel free to stay there and check the documentation on our website and all of these functions we're doing today are available via command line as well.
And in this first video, we're going to focus on depot creation. So that way, if you are making depots per project or things of that nature, you can quickly spin things up and get your team and your studio operating.
To launch the P4 admin tool, you can either launch the application directly or if you are connected to your server through P4V, you can go to tools administration as well, which will launch that server. Typically, when you open P4 admin, you will be greeted with this home screen, which will give us a kind of an overview of information about our server and how things are running. If we have user licenses available, things of that nature, but for depot creation, we will step over to this depot tab here.
Now to create a new depot, you can either go to file new depot and create something there, or you can also use the context menu by right clicking on an existing depot to go to new depot.
Now, personally, when I create new depots and things of that nature, one of the things I like to do is I like to set up a depot per project. So we'll go ahead and just name this one demo_project_depot. And the intention there is that. With that separated depot, it can be a lot easier to track permissions and who has visibility into what if you have everything separated out into its own depot at kind of that root level.
One other thing that also is nice is that when you are finally finished with a project and it comes time to archive that off your system, you can go ahead and archive that into your depot and all of that can be moved over to cold storage or something along those lines. So that way it's not on your more expensive, likely faster storage.
If I go ahead and say that this name is good and click OK, we'll next be presented with a form to fill out to ask us what type of depot we'd like to create.
Now, you'll notice that Stream Depot is our default these days, and that is because that's where a majority of our development is in line. And it also allows you to create your various code lines off of a single depot and track all of that with ease of merging and trackable merging and and all of that.
So I highly recommend using streams depots. If you haven't experimented with those yet we also have videos that we'll link here as well to kind of go through the different types of streams and the value that they bring.
The other types we have available here, we do have a local depot, which previously was called our classic depot, which is just a depot that is still stored locally on this machine. Not much different than streams. However, that one is more of that standard style where it is going to store in a standard folder hierarchy, and then all of that sort of, branching and masking and all of that is handled on a workspace level as opposed to within streams where you can pre set that all up and then use those to handle your merge and your integrations.
After that, we do have our spec depot. Typically, you have one of these per server that will handle the spec of all of your server streams and workspaces and things of that nature. So there will be one of these by default. You're typically not going to need to be creating one of these per project or things of that nature.
If you are pulling content over from a different Perforce server onto your server, you can use a remote depot. That style is read only but that will copy and allow you to copy data from a remote perforce server in now, if you are planning to want that read, write access, and it is within your organization, you'll probably be looking for a different server architecture to allow for that.
Maybe a forwarding replica or commit edge, which allows that read, right? this would be kind of more for perforce servers that you don't have direct access to, or maybe you only have a single user to contact in and pull things over.
A few more here. We've got our archive depot type. And what this allows us to do is, again, if we were then archiving our depots, our streams depots over, we can set up this archive depot type and point it to a different set of storage. Perhaps it's cold storage and the intention here is that once you've archived your files, and they've moved those revisions off of your quicker storage to the slower style, you can also detach archives. So that way it's not spun up constantly. So that would be for finished projects or possibly revisions that you would like to keep and keep the metadata available for without having immediate access to.
Underneath that, we've kind of got the opposite where archive is for those revisions unload is more about our database records and removing sections of our database records that are not used very often and writing those off to their own separate depots. That way, they don't have to be loaded into our tables at all times.
And then finally, at the end, we have graph depot and a graph depot is actually a way to store Git style graph repositories and depots within your perforce server. To access these and use those, you would use our GitConnector tool to either be mirroring from Github into your Perforce server, or using that GitConnector to connect to this graph depot directly and operate on things with Git commands.
So those are our depot types. And again, our default is a stream type, and I would recommend you stay there. And unless, you know, specifically, you're looking for a different depot type or there's a particular reason that you'd like to not use streams and go for a local depot, but local and streams are the two main categories.
Within here we do have our stream depth, and that is going to be how far down a folder structure your streams are going to begin. By default this is 1. If you look at our proposed path here, We would have depot root. So demo project depot slash, and then our stream name would land right there. If you need to have further folder structures and all that, you can add that in. So it would be demo project depot, another folder in between, and then our stream would be then made at that second level. It's up to you and depending on how your studio has to work. So here, I'm just going to leave this at one and go ahead and hit create.
And this has created our streams depot and everything is available here. Now if we were to switch back to P4V, we can quickly see that if I refresh my load, my, my screen here, that I am able to select that demo project depot. There are no streams created yet but I can very quickly come in here, create a new main line, and we'll call this demo_project_main and give it our depot name and create.
And so now we have a stream depot to now start associating workspaces with and storing our data within our streams depot. A streams depot can house any number of main lines, and off of those main lines, you can also have any number of development streams or branches or things that you need to do. You can, if you had to, or if you wanted to, within a single strange depot, create many main lines, perhaps one for art assets, one for code assets, and then import those across into one another as well.
So I hope this helps and I'll see you next time.