Teamwork

Teamwork explained

Version control is all about teamwork. First, it helps developers who are working on the same codebase to avoid making mistakes. Then it helps you find the right balance between isolation and collaboration. Some development teams these days tend to work in isolation. Each team member works in their own little world, so they don't have to worry about others breaking their code. This is not the ideal development OR business practice. Version control helps you collaborate, helps you work together to achieve a common goal and make the project a success.

Creating a repository

The repository is the database where your code is stored, as you already read in the preceding pages.

There are several rules of thumb for repository creation, but let's start with the simplest one.

Repository Creation Rule of Thumb: Create a new repository for every new project you're working on.

How do you create a new repo on the GUI? Click on the Repositories & Workspaces section in the left panel and then click Repositories. In the repositories view that opens up, click the Create new repository... button. You will get a window like this:

createnewrepo.png

You have to type the repository name (normally related to your project name) and then the server where you want to create your repository (your Plastic server).

Once the new repository is created it will show up on the list of available repositories. Then you can populate it with whatever code you already have and start working on it.

FAQ: Should I create a new workspace to work on my new repository?

ANSWER: It depends on you. If you want to reuse your current workspace to work on the new repository, just right-click on the repo, display the branches in it (in a new repository, only /main branch is present) and switch to it. It will unload your current code and download the new one (right now it's just an empty repository).

Join the project

Once you've created a new repository (project), how can your colleagues join it?

Pretty simple, there are two options:

  • Ask them to create a new workspace, select the right repository from the combo box, and once the new workspace is created, update it. (Note: Don't forget to update the workspace by right-clicking on the root of the workspace on the items view and selecting update, otherwise the newly created workspaces will be empty).
  • Switching their current workspaces to the new repository. As we described above, just show the repositories list, right-click on the right repository, show its branches, and switch to it.

How many workspaces?

This is a matter of taste; it really depends on the way you prefer to work.

If you have several open projects at the same time, maybe it's worth it to have a workspace for each of them, so you don't have to update the entire workspace (unloading all its contents and then downloading the new ones) every time you switch from one project to another. It saves time.

Once a project is finished, however, I'd simply reuse the workspace for something else or remove it, instead of keeping it around forever. As I said, though, it's just a matter of preference.

Do keep in mind that a workspace is not tied to a specific repository and this relationship can be modified at any point.

Create a baseline

Have you just finished importing your initial code into Plastic? Is it compiling? Is it ready to be shared with the rest of team members? If so, it's the right time to create a baseline!

What's a baseline? Very simple: a label. It's a snapshot of your code at a given point in time, a mark, a tag you can use to rebuild this status later (ok, there are other ways like using changesets, but this is the best one).

A label is just a human-friendly name that you assign to a specific changeset, so what you are labelling is indeed the state of your code at a specific branch and point in time.

To create a label follow these steps:

  • Open the labels view by clicking on Labels inside the section Other actions in the left panel of the GUI.
  • You will see the labels view (with all the labels you've created so far, if any). Click on create new label and a window like this pops up: .
  • Type the new label name and comment.
  • The changeset to label is the most important field. It tells Plastic where the label is being applied. The default value is the current changeset loaded in the workspace, so you are applying the label to the versions of items that are in your workspace and are checked in. Nothing prevents you from typing a different changeset, if you know that you want to label a different state.

Now you've created a new baseline.

About label naming conventions

Labels are very important to keep your project running smoothly. Avoid weird or meaningless names and try to come up with a well-defined naming convention.

We at Codice name every new release as BLXXX (from BaseLine): BL000 was the first ever Plastic internal release, and BL187 was 3.0. Every time we create a new internal release (which should be done frequently) we label the entire project.

So I suggest you decide on a good convention for your team, and apply the labels accordingly.