The 2015.1 release of Helix introduces our distributed version control capability. In this tutorial, we will cover some basic concepts and walkthrough a few common operations. You can apply two workflow models to our distributed versioning.

First, you can work from a personal server on your local machine. This means that the entire history of a file resides on each user's personal server. This model enables users the freedom to experiment without interfering with others. It also allows you to revise and rewrite history if needed.

The second model enables a user to clone a project from a shared server or servers. Users can work disconnected from the shared servers until they're ready to push content or fetch content from shared servers. With Helix DVCS, you can clone a subset of the project from the shared server so you only copy what is required.

Native DVCS workflow enables you to share projects with the shared repository while simultaneously having your own personal repository. You can push and fetch content on all these servers with the protections you are accustomed to in the Helix master server.

The DVCS model makes it ideal for large projects where team members are spread across the globe. Advantages of Helix DVCS include the ability to split projects into multiple repos. Select relevant content, clone, and work offline with better performance for large clones.

Once you've downloaded and installed Helix 2015.1 you can start working in a distributed environment. Here I have the UniClient project that I've been working on. As you can see all I have is the src directory, which is not being versioned. "P4 set" shows my currently set Helix variables.

Let's initialize this project with the new command "p4 init" with the flag -C0 to set my repo as a case sensitive.

Here we see what p4 init creates, a p4ignore and p4config file as well as my hidden directory p4root, which contains the database files of my personal repo. Do not make any changes to the database files as you can damage your repo.

Issuing the p4 set and p4 servers commands, shows my personal repo is now initialized. Let's go into the src directory to start working on my project. When I issue the p4 changes command I can see I don't have any history yet.

The "p4 status" command inspects my workspace for work I've done on my project, checking the status of my files. It tells me these files should be added to my repo with the reconcile command. So let's run p4 rec short for p4 reconcile.

p4 rec opens my files for add, delete or edit. Puts these modified files into a pending changelist so that I can then submit them to my personal repo. Now I have a change and the "p4 changes" command shows this history.

Let's make some more changes to some files, then run p4 status which reports back that I should reconcile my work.

p4 status, shows I've updated some of my files.

p4 rec, adds these files to my pending changelist.

p4 submit -d, to submit my changelist.

p4 changes, shows me my history of my updates to my files.

DVCS has the flexibility to create branches when needed. So let's create one. Let's create a new dev branch with the new "p4 switch command". The p4 switch command will switch me to a different stream, or create a new stream for me. The -c flag creates a branch and dev is the name of my new branch. On creation "p4 switch" automatically switches me to that branch, you can see this by issuing p4 switch -l. The -l flag lists my branches in my repo. The asterisk indicates I'm on the dev branch. Let's modify a file in this dev branch and submit the change.

p4 rec, to add to my pending changelist.

p4 submit Ðd, to submit my change.

p4 files, shows me my changes in the dev branch.

When I switch back to main "p4 files", you can see that main does not have my change from the dev branch. If I want to merge that change back to main I use the p4 merge command. The Ðfrom flag is new in 2015.1 to p4 merge. It specifies which branch I am merging from in this case the dev branch. Now we need to resolve the file with p4 resolve. And finally we submit that change. p4 changes to take a look at that change.

That's how easy it is to work in your own private repository. With the flexibility to create as many branches as needed and experiment until you are ready to collaborate with a larger team.

Now let's switch our strategies and work in a shared repository. I'm going to clone the Jam project out of my company's master server. For that, I issue the new p4 clone command. p4 clone -p from the server the remote server.

The new p4 clone command, clones a new private local Helix repo from a remote. It fetches all project files or if I want a subset of project files from the remote. It also creates my configuration files (p4config, p4ignore), and my hidden .p4root directory.

To see the configuration of my server I run the p4 servers and p4 remotes commands.

p4 servers shows me the name of my personal repo.

p4 remotes shows me which remote repo I cloned from.

Let's run p4 changes to see what we pulled down from the master repo. There are only a few changes from the master. Let's do some work in the src directory by making some changes to a couple of files.

p4 rec, Let's reconcile our work.

p4 status, just making sure.

p4 submit -d, to submit that work.

And p4 changes, to see that recent change.

Now let's switch our view to Aruna Gupta who is another developer also working on the Jam project but using P4V as her client. She is updating files in the Jam project and is submitting a change to one of the same files I'm working on.

Let's see how P4 DVCS handles that as we switch back to my view. To submit changes back to the master repo we use the new "p4 push" command.

Ahh that fails with a warning, "Conflict: Cannot push changes. You must fetch changes from the remote server first, using the fetch -u command". P4 is instructing us to fetch the changes in the master and unsubmit my changes with the -u flag. Let's try it.

"P4 fetch -u" pulls down the changes that were made in the master repo and unsubmits my changes in my personal repo. I can use the "p4 resubmit" with the "-m" flag command to replay my changes and merge the files I've just pulled down.

Now that I have successfully resubmitted my change, let's push them into the master repo. Finally, let's switch views into the master repo and review those changes via P4V. Here in the submitted changelist tab we see two new changes, the one from Aruna and Joe.

And that's how easy it is to work in a P4 DVCS environment. With all the commands you are accustomed to plus a few extras to help you work in a discounted environment. For details on the new commands just issue p4 help and that command.

Thanks for watching.

Course - Distributed Versioning