Full Video Transcript
Hi everybody. I'm Jase Lindgren, a solutions engineer at Perforce Software, and this is part one of a two-part video where we're talking about file operations in P4V for Helix Core. So in this one we're just going to cover the very basics of checking out files and submitting them, and then getting those revisions from others. And then in part two, we're going to move on to some more advanced things like rolling back changes.
Now let's talk about how we make changes to files and then submit those back to the server. So right now we have a workspace that is connected to a stream, and then we've run get latest. If I wanna make sure I have latest, which is a good habit to get into, I can highlight this root directory here and say, get latest revision.
Or I can click this get latest button at the top. Be sure you have this root level directory selected when you do that if you want everything. If I only wanted to update files in a certain subfolder, or maybe even just check that I have the latest of a particular file, I can right click and say, get revision on that.
Or, click this folder and say, get latest. But that's only going to run for that folder I have selected. So be sure you have this root level one just so you can make sure you have everything updated. One quick thing to note is that the Helix Core client, so in this case we're using P4V or if we did this with the command line, what it does is it syncs these files to your local file system, but then it also makes them so they're read only.
So if you come in here and you were to look at the properties, you would see that this little read only checkbox is checked. Same thing is true on Mac or Linux, where it's going to remove that write permission. And the reason for that is that you don't wanna make changes to these files without Helix Core knowing about it so that it can track those changes. Let's say I open up this requirements txt file, and let's just add a little comment line here.
If I just try to save, you'll see, I, I get this dialogue that pops up that's saying I can't save. You need to save it as is the purpose for this, right? And the reason for that is because that file is marked as read only.
But if I check out that file, so that's the requirements txt. And you can do that by right clicking and choosing Checkout. Or as you can see at the top, I can click this Checkout button here. Or there's also a hot key, as I mentioned over and over,
there's usually at least two or three ways that you can do something. So find the one that works for you, but it's good to know about the others. So what I wanna do is check this out. If I hit check out, you can see there's a red check mark that shows this file is checked out and now if I come back here and look at its properties, I will see that read only is no longer checked.
And if I come back into here and I add comment here and I go to save, I now don't have any problems. That’s saved. If I open it again, I'll see that change is still there. Now the important thing to note is that this change is only on my local machine and not to anybody else. So one quick thing that we can see here is that one of the important reasons for checking stuff out, in addition to being sure that you know which things you need to submit, what things you've changed, it also allows other users to see what files are being worked on.
So in this case, if I switch over to my Mac, I'm in a different workspace that's working in the same stream. And you can see here, I apologize that it's a little bit tiny on the screen, uh, but there's a little blue check mark here on this instead of the red check mark we had on the computer that has it checked out. And what I can see here is that this is checked out by a user at a workspace. In this case it's my user, but in a different workspace.
So you can imagine how helpful this would be if you can see, oh, oh look, Julia's working on this. I thought I was supposed to work on this. Let me go check with her and, and make sure we're coordinating on what we're supposed to do. So if I go back over to my Windows computer, and I can see here I have that checked out.
Now, when you check out a file, it will go into a Changelist, and if you want to see your Changelists, you go to this tab called pending or Pending Changelists. Again, if I had this closed, I can go to the plus icon and say Pending Changelists. What a Changelist is, is literally a list of files and what's changing about them. So in this case, I have my default one here.
If I click this to open it up, I can see that inside of it is this file, this requirements.txt file that I made a change to. It has that red check mark on it so that I know I made a change to this and if I want to submit this to the server, I then submit this Changelist. One of the things that makes Changelists useful, in addition to, as I mentioned, you want to be intentional about deciding when to submit your changes, is, let's say I've done multiple things.
So let's take another example where I want to edit this image file. So in this case, I can check it out or I like this command check out and open, which is handy. And you can see I've opened this up and let's say I need to make an annotation of like, okay, that that's better, that that's clearer about what it should be. And I will save that.
And now you can see that I have two files here in this Changelist. The idea is that by submitting multiple files in one Changelist, you're able to make it clear that all of these changes go together as in, you know, I changed my readme file and some of the images in it, or I changed this model and the textures that go on the model, or I've changed these multiple pieces of code that all interact with each other so that you can submit those all in one batch. So it's more clearly tied to the task that you did. And that ties into the other feature.
Let's say, this is the change I wanna make. I'm now going to highlight this Changelist and I'm gonna click submit up here, or right click and submit this way. When I do that, I get presented with this dialogue wanting me to write a Changelist description.
So this part is super important. So, you know, one, I can check the files or the ones that I expected down here, but I can write a description of what I did. So here I can say, "added better comment to requirements and added nice illustration to the running tool image." Usually you don't need to mention the file names themselves because you can see that along with the Changelist, but this is where you can explain what is the task that I did here, and then when I'm ready, I hit submit and you'll see progress down here as that's uploaded to the server.
Now you'll notice my pending Changelist is empty because I’ve submitted that and now all my changes are done. These are also not checked out anymore. They're now checked in and you'll notice that this version number has gone up. Requirements.txt was four of four before.
Now it's five of five, and running tool was one of one, and now it's two of two. If I want to see these past changes I've submitted, we can do that by going to the submitted Changelists. The pending Changelist is what you have ready to submit. Submitted Changelists is what you have already submitted.
You'll notice up at the top, there's a little filter here. Just as an FYI, by default this will be set to current users, so you're only seeing Changelists by yourself. And I can also set that to only see changes in my current workspace, which in this case would only be that one because I just created this workspace and created this.
If you were to clear out both of those, you could see all changes from all users, which can be really useful if you're looking through the history. And you'll notice that I have my description here, who submitted it when they submitted it, as well as what files there were. And if I hover over them, I can see that was an edit and this was an edit. If I added a file or deleted a file, I would also be able to see the fact that I made that change.
Now let's switch over to our Mac user to see what happens over here. Over here you'll notice that now my requirements.txt, I've not gotten latest yet, so I'm still on version four. But there's now a version five or revision five is what we call it.
And you'll see I have this little yellow triangle that shows up on that file saying, "Hey, you don't have the latest of this. Be careful before you do anything with this file." And if I actually try to check this file out, it's gonna say, if it's gonna say no, you can't do that because you don't have the latest version of that, because I don't wanna be making changes on an out of date version. So I'll just hit cancel here.
And what I'm going to do is, again, I could just get latest of this one file, but I usually will go up to the route and say, get latest, and you'll see really quick now I'm on version five of five, and if I open that up here, you'll see I now have that comment here, just like I added in my other workspace on my Windows computer. I hope that was helpful for everybody. In part two I'm going to move on to some more advanced operations, like reverting changes that you don't want, undoing changes that have already been submitted, checking out how the project was at previous points in time and reconciling offline work to make sure that you have all of the changes in Helix, Core, even if they happened outside of that system.
So I will see you in the next one.