Why version control and Plastic SCM

What's Plastic SCM?

Welcome to Plastic SCM!

We've created the most advanced version control system to date, and in the next few pages, we'll explain how to get the most out of it as quickly as possible.

As a busy developer you'll appreciate that we hit the key topics right on the head. That's the intent behind this guide.  So first, let us tell you what Plastic SCM is about:

• Plastic is a version control system: it versions files and directories and keeps track of branching and merging as you've never seen before. And even better? It does it in a graphical way.
• Plastic is all about three key concepts:
  • Parallel development: Team members work on the same files, at the same time, making changes without interrupting each other. That's how modern teams work, and that's how you should be working. Plastic lets you work this way by isolating changes on branches and handling them in an agile way. Excellent branching coupled with better merging enables teams to work together and trust that their changes and code modifications are protected and preserved. You just make changes, Plastic takes care of the rest.
  • Distributed development: Plastic helps optimize the collaboration of distant teams. You can have Plastic SCM servers in different offices in different parts of the world, totally disconnected from each other during the major part of the day, and then exchanging branches back and forth in the off-hours to keep in sync. Teams don't have to depend on their internet connections (speed, reliability, and so on) since they can continue working independently. The same technology applies to individual developers working off-line. A small footprint Plastic server is installed on developers' computers. Only when they get online, or are back at the office, will they need to sync with the main server.

Marketing warning!!! These days, distributed development is a buzzword, so every SCM out there will say it works in a distributed way. The problem is that most of them claim this when all they mean is that they can work through the internet using a TCP connection. That's not distributed, that's centralized through the internet! Distributed means the ability to work offline and exchange branches back and forth.

• Making it visual: Plastic SCM is able to perform very complex operations, but we try to do everything visually, with graphical representations and 3D diagrams. Everything is just one simple click away. Hard core command-line users can always find their way through our command line, but the rest of us prefer a strong GUI capable of turning complicated, multi-dimensional actions into simple affairs. That's Plastic.

Why version control?

Skip this section if you already know why. If you're new to version control, let me ask you some questions:

• Did you ever create a zip file to store your sources?
• Did you ever create a second version of this zip file?
• Did you name it something like sources.today.zip and then sources.goodones.zip and even later sources.good-the-real-good-ones.zip?
• Did you ever overwrite changes made by a colleague on the team by using these truly 20th century practices?
• Have you ever needed to know "why was it working five minutes ago and now it's broken"? And then did you later found yourself unzipping and manually sorting through a nightmare of commented out code to figure out what you really changed?

If any of these sound familiar, you need source control.  (Note: Okay, I've covered pretty basic and kind of funny situations, but admittedly these nightmares tend to happen when you don't have a version control in place.)

A version control will help you:

• Organize your different releases. No need for zip files with funny names anymore. Just create a label and apply it. That's how professionals do it, and that's how you should do it.
• Keep track of every change and be able to find it later. There's no more guessing. You have the ability to go back in time and see why something was working (or not) for every single change.
• Run experiments: Do you want to try something out and later decide whether you can move it to the real version or not? No need for alternative paths with copies. Create a branch and do your experiments there.
• Combine changes made by different team members without the risk of losing any of those changes, even when they were made on the same files!! No magic here; it's called merging and you should get really familiar with it.

Sound good enough? Then jump to the next section.

Still need convincing? Well, then let me give you a few more reasons:

• Keep the most important software phases in sync: Developers get connected to testers. They know what and when to deliver. A good version control system does this effortlessly.
• Reproduce bugs: A customer found a bug on a certain version of your software. Do you know how to reproduce it? Can you rebuild exactly the same version in a matter of minutes and apply a fix to it? How are you going to handle this bug fix? To solve all these problems, you need version control that supports branching and merging.
• Organize development activities: How do you close the gap between the tasks in the project plan and what developers end up doing on a daily basis? Do you use an issue tracking system? (If you don't, go and grab one!) How do you keep track of what was modified for each bugfix? For each new functionality? Plastic SCM manages this and more.

Ok, I hope you're now ready to jump into the next topic.

You're still here? Ok, then believe me, if you want to make money through professional programming, you need a version control system. Even if you want to contribute to an open source project, you're going to need to use one to coordinate with the community. Plastic SCM can help you on both counts.

What's a server? What's a client? (The basic structure.)

So, you're finally here! You do want to know what Plastic SCM is about, don't you?
Since you're a programmer (or at least you have a programming background, otherwise why are you messing around with code! :-P) you'll definitely appreciate wanting to learn more of what's behind the scenes.

At face value, Plastic is really simple.  There are only a few moving parts, so let's take a look at the following components:

• There's a server: It keeps track of your changes. Every time you check in code, the code will go to a server. It will keep track of storing your data and additional information (like who did the change, when, why, and where) on a database of your choice (several standard backends available, more on this later). It's the brain behind Plastic SCM, where the logic is implemented. The server is a Windows Service or a Linux daemon, depending on which platform you're on. All data is going to be stored on databases called repositories (more on this later, just remember the name).
• There's a client: It's sitting together with you to help you communicate with the server. The client can be a GUI tool (like our great graphical user interface system with lots of graphics, visualizations, and views), an integration with your favorite IDE (Visual Studio, Eclipse, IntelliJ), or a command line application to automate stuff or simply type commands. Normally you'll have your code in a directory and your client will work on this directory, this is called the workspace and you'll learn more about it on the next section.

How does communication happen?

• Communication will always happen in a unidirectional way from client to server.
• The server listens on a single TCP/IP port, waiting for the client (or clients) to perform some action. The default port is 8084 (keep this in mind for firewall-related jobs!) and it's configurable by editing the remoting.conf file (check your server's installation directory).
• Communication is compressed and optimized so that it's as efficient as possible and more efficient than any other SCM on the market.
• A Windows client can communicate to a Linux (or MacOS X) server, and the same is true for any other combination. There are no platform restrictions and no special set up.

Are you always going to work with a single server?

• Initially yes: when you install Plastic, you get a client and a server installed and you can start playing with them.
• If you're on a team sitting in the same office, most likely you'll have just a central server, and then all clients configured to work with that server.
• You can also have a server on your workstation or laptop (or even on both) and replicate changes back and forth with the central one or with your peers (the magic of distributed version control, DVCS!!). You'll find this is a powerful scenario.