Hi, I'm Ryan Maffesoli with Perforce Software. And in today's video, we're going to talk about how to set up your Helix Core server to automatically ignore directories within your workspace that you don't want to have pushed up into revision control. So this can be really important when working with certain game engines or certain workflows that may generate cache directories that don't provide valuable data that we need to save. Or even if you just need a directory for your users to act as a scratch directory or anything like that. So without further ado, let's hop on in.
Alright, so there are two main methods of ignoring files from your workspace and kind of blocking them from being pushed up into your depots or streams.
The one that most people are probably familiar with would be the p4ignore file. The way that people ignore file works is very similar to ignore files and other revision control systems.
So for my current workspace here, if I were to jump into my P4ignore file, we can open that up. And as it's just a normal text document, it's going to open up into whatever your preferred text editor is. Now, if we take a look in here, you can see that we have both folder level patterns that can be matched as well as file extension patterns that would be matched. And also sub file patterns that can be matched and anything that matches any one of these patterns will be ignored and no longer be allowed to be marked for add or to be submitted back to the server. So, as mentioned, you can see any solutions files, anything in the templates folder, everything along those lines will be blocked and kept away now one file I typically always add to my P4ignore is my p4config file. And the reason being is that file is typically user specific and workspace specific. So if I were to upload that to my depot, And someone else pulled that P4 config down, depending on the variables that are being addressed within it, it may not work for them. So I always typically include that in my ignore to make sure that anything that is user specific to me, does not get uploaded to the server.
One thing that can be a little tricky about a P4 ignore file is that you do have to set a specific environment variable. For this file to be picked up and used within your workspace. So if I were to come down to a command prompt and particularly my workspace here, if I were to just run the p4 set command on its own, it will print out all of the environment variables that are currently in use and set for this workspace.
Now, these could be set globally for the system. Or these might be picked up from your P4 config file. And so here you can see that I do have a few that are set that are specific to what we're doing right now. I've got my P4 config set to .p4config is a file name because it's just a single file name.
It is a relative path and it will pick up any .p4config file that I have in my workspace and use that. So you see, I do have that here. And if I take a look in my P4 config file, I'm just defining some very basic environment variables for Helix core to use when I'm within this workspace. And one of those values is the location and name of my P4ignore file.
Now you can see here that I do also have my P4ignore being defined as that .p4ignore. as mentioned, that can be picked up from either the config file, as it's shown here, or we can set that explicitly for the machine if we would like to have a fully defined path, or if we would just like for every workspace on this machine to pick up that value by default.
So to do that, we would do P4 set, P4 ignore equals dot P4 ignore. And that would set that as an environment variable on the system. No matter if I have a P4 config file set up or not.
So with my p4ignore set here, if I were to come into p4v and right click and say mark for add on the top level of my workspace, it's going to go and run through and try to find any file that hasn't been currently marked for add within my workspace and attempt it. Now it will filter that against our p4ignore file. And so down here, you're actually seeing where certain portions of my workspace are being excluded because of those file matches. So particularly here, it's this Saved directory that is being ignored by our P4ignore. And so it's telling us that this file is not in our client view. And essentially this file is not part of our workspace. So even though it's a subfolder because of our P4ignore, it's being excluded. And so from the top here, you can see that again, I've grabbed my entire workspace, but if I were to come to my pending change lists, I haven't added anything new because that P4ignore has kept me safe from those folders. So anything in intermediate has been excluded ,anything in saved has been excluded, even though there are plenty of files. And again for work with game engines, this can often be very important to not clutter up your system and try to save more data that isn't valuable, and also you don't want to put possible file locks in place for some of this derivative data that's going to change on most people's systems quite often.
So that's how a p4ignore file works, and it can be very useful if you have complex paths you need to ignore. For instance, here you can actually see that We have wildcards within our path any folder, within engine programs if there's a save directory, we're aiming to ignore anything. So any sort of complex pattern should go into a p4ignore and that's the easiest way to handle it.
Now, there are some caveats with the p4ignore file as well, that if a user were to delete that file and then Run it again. Since that file, that filter file is no longer in place, you would not have that protection and files can end up on your server that you may not want.
So typically, it's always a good idea to check that before ignore into your depot. So that way, everyone gets it pulled down. And then as an admin, you're going to want to make sure that everyone has their environment variable set on their system.
Now the next style of ignoring files is more server side, as opposed to being run on the client machine itself. And what we're going to do for that one is actually affect the view as defined for one of our streams in a streams depot.
So for my workspace here if I go over to my stream graph, And I just have my main line here for this demonstration. I can right click and go to edit stream. And within this view, if I step over to my advanced tab, beyond our paths and our ability to import things in from our other streams and the ability to remap files and folders to different locations if we need to, we also have the ability to ignore things directly here in that stream view. What's nice about using the stream view here is that you define it on the server and then any workspace that is created off the stream automatically gets those ignores applied. So it doesn't require that you set environment variable. It doesn't require that you set that P4ignore file up correctly. You just define it on the server and the server is going to be the one blocking these files. Some caveats that go along, here, the syntax is slightly different. So in this view, we are using our, Helix core style syntax, where if we would like a recursive wildcard, we need to use the ellipses .And then the other thing is we can't do complex paths in this one. Now, the reason being that this ignore list is being processed by the server itself, as opposed to the clients. And since you have only one server and possibly many clients, if we were to allow those wildcards within those paths, the patterns could get a little more complex and cause a lot more processing to check all of those. So typically here, if you're ignoring full folder levels you can define those folders out, followed by ellipses to say anything underneath, and then you can also define individual files, or if you have various file extensions, you can just define those outright. You don't have to have a preceding wildcard in this instance for these to work. They will apply to everything that's associated with those. So once this is defined here and we go ahead and hit save and apply we've applied that to our stream and that will now affect everything in that stream.
So even without that before, ignore my stream will stay clean and all that. That can be a really good option. If you have users that are a little more unfamiliar with Helix core or P4V. And might not understand that they need to have that p4ignore set in place initially. where it's not going to be as strong of an option is if you have very specific ignore requirements and that you need to make those paths a little bit more complicated than you'll want to lean towards that .p4ignore file and then store that back into your stream. So that way it can be downloaded to every client
And with that, you now have two options on how to keep your Helix Core server clean, and keep unwanted data from muddying up your streams. Have a good one.