The Plastic SCM blog

Designing a better user experience

A few days ago we were working on the new "method history" functionality and then we were making fun about the error message to pop-up when a user clicks in the middle of two methods (it doesn't find any method then) and tries to find the history of the "non-selected" method (well, we're the ones to blame here because probably a disabled menu would work better :P)

But, you know, sometimes you would like to come up with very, very strong error messages... wouldn't you? :)

So, considering today is the equivalent to April Fool's day down here... what about having some fun?? :)

Ok, and now the real video (remember it is already available in the latest Plastic version, yes, history of a method!!):

SSL Enabled Plastic Connections - Reborn!

NOTE: This article is updated and maintained at this link here
Here are the instructions on how to configure Plastic SCM release 3.0.187.x
(x > 0) to communicate using a secure SSL channel between the client and server.
First download and unzip the following package. PlasticSCM_SSL_ConfigFiles.zip. Next we are going to copy these files to specific locations.

Server setup:

Stop the Plastic SCM server service from windows services

In Windows goto Start->Run->type "services.msc" and find the Plastic Server service and stop it.

Navigate to your Plastic SCM server installation folder and rename your current remoting.conf file to remoting.conf.bck.

From the zip file server folder extract the new remoting.conf to the Plastic server installation folder.

The provided remoting.conf file will configure your server to use the default TCP port 8084 for non-SSL client connections and TCP port 8085 for SSL connections.

You can change the Listening ports above by editing the remoting.conf file.

A plastic.key and a plastic.cert files should be generated for the SSL to work, these files should be placed in the Plastic SCM server folder.

to generate the files, we will use a certificate generator tool makecert.exe obtainable from the .NET SDK:

http://msdn.microsoft.com/en-us/library/bfsktky3%28VS.80%29.aspx

use the following command from within .NET SDK command Prompt: c:\>hostname

record the above hostname to use it in the following command to generate the certification files:

c:\> makecert -r -pe -eku 1.3.6.1.5.5.7.3.1 -n "CN=hostname" -sv c:\plastic.key c:\plastic.cert

see Figure 1

If a pop up window “create Private Key password” is shown, choose None as illustrated in Figure 2

Copy the generated plastic.cert and plastic.key from c:\ to the plastic scm server folder.

Edit the remoting.conf file for the plastic server to point to the above generated certificate files; find the section and update it as illustrated below.

<channel type="Codice.Channels.PlasticSecuredTcpChannel, 
 plastictcpchannel" port="8087" 
 sslCertificateFile="C:\Program files\PlasticSCM\server\plastic.cert" 
 sslPrivateKeyFile="C:\Program files\PlasticSCM\server\plastic.key"; 
 name="secured">

Start the Plastic server, and check the connections on the server machine to verify that server is listening on the right TCP ports, executing the following command from a command-prompt c:\>netstat –na –p TCP as illustrated on Figure 3

Client setup:

To enable the Plastic SCM client to connect to the Plastic SCM server using SSL, first extract from client folder within the zip file, the file remoting.conf that should be extracted and placed in the Plastic SCM client installation folder.
Complete the setup following the below steps:

re-run the Client configuration wizard, and point to the port that is used for SSL, in our case port 8085.

edit the client.conf file adding the following line:

<ServerProtocol>ssl</ServerProtocol>

see Figure 4

if you want to use the previous non SSL connection, you must remove the above added line in the client.conf file and re-run the Client configuration wizard, and point to the port that is used for non-SSL connections, in the default case port 8084.

The makecert.exe program is part of the Windows SDK, so Windows developers probably already have it. We found some easy instructions on doing this on another blog post here.

Setting up two Plastic SCM installations on the same machine

A single machine can host multiple Plastic SCM installations -- that is, multiple instances of a repository server process, each with its own set of repositories. In this post, I'll address a specific case:

You have already installed Plastic SCM on a Windows machine. Now, you want to create a second Plastic SCM installation on that machine.

Here's the recipe:

To provide a home for the second repository server process, "clone" the server subdirectory within the Plastic SCM installation directory. For example, you can use Windows Explorer to Copy the server directory, then Paste it in the same location. Rename the new "clone" to server2.
You need to reconfigure the repository server process to listen on a different IP port (say, 8085). In the server2 directory, run the configureserver program to make this change.
You might need to reconfigure Plastic SCM's connection to its database back-end, so that the second installation uses a different set of database files. Still in the server2 directory, see whether file db.conf exists. If so, add a <DatabaseSuffix> subelement to this XML-format file. For example:
```
<DbConfig>   ...   <DatabaseSuffix>_s2</DatabaseSuffix>   ...</DbConfig>
```
If no db.conf file exists, the repository server is using the default database back-end, Firebird, which is embedded in the repository server and requires no configuration file.
You need to create a new Windows service for the second instance of the repository server process. Open a command prompt window in the server2 directory, and run this command:
```
plasticd --installservice --servicename=PlasticServer2
```
Alternative: use the Windows command-line tool sc ("service control"). Be sure to enter the entire command on a single line, and to leave a SPACE after each "=" character. For example:
```
sc create PlasticServer2
   binPath= "C:\Program Files\PlasticSCM"\server2\plasticd.exe
   DisplayName= "Plastic Server 2"
   start= auto
```
Start the second repository server process:
```
net start PlasticServer2
```
Use Plastic SCM client software to remove the "cloned" repositories from the second Plastic SCM installation. (This is necessary only if you're using Firebird embedded or SQLite and your databases are in the server's directory!!) For example, using the CLI's command for removing a repository:
```
cm rmrep myoldrepo@mymachine:8085
```

Plastic SCM Plug-in for Hudson CI

In this blog post we will go through the very basic steps to setup Plastic SCM Plug in for Hudson CI and do some builds.

The Plastic SCM plug in developed for Hudson CI is basically an .hpi file which will be included in the HUDSON repository (working on it).

However, you can download the plug in from this link: Download_PlasticSCM_Plugin_for_Hudson
Just unzip the hpi file into .hudson/plugins, restart the server, and it should work.
For this Blog post my setup involves the following software:

OpenSuse 11.1_x86

Plastic SCM version 3.0.187.22

Hudson CI ver. 1.384 (also tried it with 1.398)

gcc-c++ ver. 4.3 (use it for compiling the Hello World sample with Hudson)

Test files you can download from this link: Download_Test_Files

Create a Plastic workspace and extract the test files into the directory of the workspace.
The test files are basically two files, a helloworld.cpp and a script file BuildHello that calls the g++ compiler and compiles helloworld.cpp. Add the files to Plastic SCM so they are controlled, as illustrated in figure1.

Figure 1

Now into Hudson:
Log into Hudson, in my setup: http://localhost:8080/

Navigate to Manage Hudson-->Manage plugins-->Installed (choose Installed Tab)
Illustrated in figure2

Figure 2

Plastic SCM Plug in should be in the list and enabled. (double checking here :-))
Plastic SCM plug in does not differ much from the other Hudson Plug ins, so let us create a project and do some builds.

New Job-->Job name: PlasticSCM_prj1-->Build a free-style software project-->OK

Illustrated on figure 3

Figure 3

Next page we will configure Source Code Managment-->Plastic SCM-->Selector (Insert Plastic SCM workspace selector, fig 4+5)
- Selector can be obtained by many ways, this is just one of them.
- CD to your workspace directory ex.cd \millerwks\prj1\
- execute cm showselector (cm ss) ex. \millerwks\prj1\cm ss
- Selector will be printed and could look like this example:


repository "default"
path "/"
br "/main"
co "/main"

On the same page under the Build-->Execute shell-->Command (Insert the name of the shell script BuildHello, fig 6)

Save

Illustrated in the next figures

Figure 4

Figure 5

Figure 6

And now we are ready to do a "manual build" without triggers, so go ahead and push the button Build Now as indicated in fig 7.

Figure 7

Well, after pushing the Build Now (for many times), I get Build failed which is not cool! lets try to find out what is causing the failing of this build.
In the Build History on the left I entered into the latest build, and clicked on Concole Output. see fig 8.

Figure 8

Ok, cannot find the build script Buildhello, checking figure 1 with figure 6, I inserted the name of the script wrongly, Buildhello instead of the correct BuildHello. So I go to the configuration of the project within Hudson and fix the name, as in fig 9.

Figure 9

A manual build now and things looks much better, fig 10 + 11

Figure 10

Figure 11

And it is by time we try if our hello program built correctly as illustrated in fig 12.

Figure 12

Announcing "method history"

We’re very happy to announce our newest Plastic SCM release (3.0.13) including one of the features we’re most proud of: method-based history!

You can now select a method within Visual Studio, right click to show the context menu, and select “method history”. Plastic SCM will go through the file history and analyze the evolution of that specific method!!

Motivation

We have the impression that 95% of the time that you go through a file’s history, the reason is to check a specific method. That’s why we came up with this new feature. In fact “method history” is one of those things we’ve always wanted to implement, but of course we had to cover the SCM basics first. But, finally, it is here!

“Method history” is our first step into a “programming language aware SCM”, a path we will be walking during the next months. We have a bunch of ideas to combine the “method history” parsing technology with XDiff and XMerge, to come up with a new line of Plastic SCM functionality in 2011.

Action, please!

First, here’s a short explanation of what “method history” is about, with graphics:

Plastic will look for the method in every revision of the item. Right now the search has some limitations (remember this is beta software):

We only parse C# code (Java is ready but not deployed; VB and C++ will be next)

We don’t consider constructors yet (but we’re on it!)

We locate the method by name: next step will be finding renames too!.

A few screenshots to see it in action:

and

And finally a video (available in HD!):

How to try

Simple: download the new release and install the Visual Studio "package" (not SCC, the newest package) and simply give it a try.

What's next?

As I mentioned, a ton of new stuff:

Being able to invoke "methodhistory" from the "annotate" views in the GUI

Eclipse support

Multiple language support + improved C#

Tracking refactored (moved) code between files... (wow! yes, we're on it! :P)

Enjoy

Why merge tracking matters

My goal with this blog post is to explain why merge tracking is so huge for all the Subversion, CVS and VSS users out there who still think “hey, I don’t care about the new SCM systems, I don’t need distributed development!”

I know the GitHubbers and Mercurial users and Plastikers out there know what I’m talking about, but for the sake of clarity: the new DVCS systems are not only good because they’re distributed, but specially because they’re able to handle merging correctly. (Yes, I hear SVN users shouting: “we do have merge tracking after 1.5”, I know, I know, and I still say… switch to another system! :P.)

So, I will try to explain why merge tracking is so important with a very simple scenario. Let’s go.

Change my code

I start with the following piece of code. We’re going to modify, in parallel, the fragment that is highlighted in blue.

Basically we’re going to do what the next image shows: one of the developers is going to make a change to the code on the “main” branch (“master” in Git jargon) branch and the other coder will modify it on “featurebranch” branch. You can visualize your Git repo history using GitJungle which displays graphics exactly like this.

Merging nightmare

Let’s go now and merge “featurebranch” back into “main”. This time we’re facing a “manual merge” because we’ve created a non-automatic conflict. It isn’t a very tough conflict to resolve, because only a small code fragment is involved. But in the real world, you sometimes have to deal with heavily modified files, and the merge isn’t so easy.

Almost every 3-way merge tool out there works in the way pictured below (whether you’re using KDiff 3, WinMerge, Araxis Merge, Guiffy or the great Scooter Software’s BeyondCompare!).

As you can see you’ll have to deal with the “base” (or common ancestor) and the two “contributors”. In our case: the file as it was at the beginning (base) and the two parallel changes made on different branches (destination, the revision made on “main” and source, the revision made on “featurebranch”).

Because we modified exactly the same code, the 3-way merge tool shows something like the following:

You, the developer or integrator, have to decide what goes into the result file. In this case the desired result is the following: we keep the new method introduced on “main” and the new loop variables introduced on “featurebranch”. And, the most important thing is: check the “merge arrow” that now is coming from “featurebranch” into “master”. It means the underlying SCM “knows” the branch is already merged. That’s the key.

And the fun starts when you merge again

What if know you need to make a new change on the same file on the “featurebranch”? Suppose the “merge” wasn’t so trivial and it took you quite a few minutes to figure out how to resolve it. I bet you wouldn’t like to go through it again, would you?

Well, the magic of “merge tracking” is that it will allow you to make a new change on “featurebranch”, on the same file, and merge it again but without having to merge again the conflicts you already resolved! That’s the key and that’s something you didn’t have with older systems (and probably the main reason why you used to hate branching and merging before…).

The following image shows how you’ve introduced a new change on the branch, and then it will be time to merge again.

Common ancestors – finding the root of all revisions

So, what will happen now when you try to merge from “featurebranch” back into “master”? Well, thanks to the “merge link” the system created before, some things will change.

Look at the situation before doing our first merge. The contributors and the ancestor are highlighted. As you can see, the changeset (commit) tagged as BL189 is the common ancestor.

But now, when you’re going to merge again, the common-ancestor calculation will be different.

Now the newly calculated “common ancestor” for the merge is the recent changeset on the “featurebranch” (the contributor to the first merge). And the results of the first merge, including all the difficult-to-resolve conflicts, are recorded in the “main” branch contributor. With all the complicated work behind it, the merge algorithm can deal only with the new changes on “featurebranch”, and merge automatically for you.

Wrapping up

So, well, that’s all: I’m sure you’ve faced a situation like the above. Only having full merge tracking will save the day!

New manual: Introduction to Plastic SCM

I'm happy to announce that a new manual, Introduction to Plastic SCM, has joined the product documentation set. It's available as a PDF, at http://www.plasticscm.com/releases/3.0.1/plastic_intro.pdf . This new "Intro" goes wide, but not deep. It's intended to give you a feel for what you can do with Plastic SCM, and for how (and how easily) you can accomplish SCM tasks with this great product!

For the most part, this manual replaces the Plastic SCM User's Guide (which also was called the "Introduction" in some places). But there is some reference-level material, such as the details of the configuration language for the workspace's selector, that is not included in the new manual. So don't get rid of your "User's Guide" bookmark just yet!

We love to get feedback on all our work, so please don't hesitate to send questions, complaints, and compliments to doc@codicesoftware.com.

A plugable Plastic SCM server

Yesterday I got a SheevaPlug development kit and the first idea that came to my mind was “hey, let’s put a Plastic server here!” I’m involved in a small robotics project at the university (I’m an associate professor in Computer Science, although robotics is not my area) and we’re evaluating different alternatives to use as the robot brain. But yes, before moving some engines I wanted to check if it was possible to set it up as a Plastic server.

The look and feel

Well, I just took a few pictures of the “pluggable computer” today, close to my BlackBerry so you can see how small it is.

Start up

First thing is to go and plug the “thing”. Then it is supposed to start up and get an IP address from your router. That’s what I did, then went to my router configuration and checked that a new box was online!

Then I followed the instructions here to connect using ssh and log in. Cool!

Setting up

Follow the instructions step by step, all of them, including the one related to the time and date settings because otherwise you’ll end up in trouble when installing packages. It takes just a few seconds to go through all the commands. (I didn’t set the date at the beginning and jumped into mono installation and… ouch! Didn’t work!)

Installing mono

Again, really simple and well documented here. It’s an old 2.0 Mono (so I will try to come up with a newer 2.8 in the coming days, but just stayed with this one for the initial tests).

$ apt-get install mono-2.0-devel

And then don’t forget to install the following one too (otherwise you won’t have remoting and Plastic won’t work!)

$ apt-get install libmono-system-runtime2.0-cil

Copying Plastic

I just copied the Plastic SCM server binaries into /root/plastic/server and then run:

$ mono plasticd.exe –console

But… it didn’t work!

First thing I hit was that the SQLite libraries installed by default on the box were not ok to work with the Mono wrapper.

Ok, first things first. Here’s my db.conf to use a SQLite backend:


<DbConfig>
  <ProviderName>sqlite</ProviderName>
  <ConnectionString>Data Source={0};Pooling=true</ConnectionString>
</DbConfig>

Installing SQLite

First I got the package and then installed gcc and make

$ apt-get install wget
$ apt-get install gcc
$ apt-get install make
$ wget http://67.18.92.124/sqlite-autoconf-3070400.tar.gz

Then I built the sources with the following flags:

$ CFLAGS=-DSQLITE_ENABLE_COLUMN_METADATA=1 ./configure && make

Then I just added the .libs path inside the SQLite src dir to the LD_LIBRARY_PATH (hey! I know it is not clean but I’m just doing a quick test!)

Starting up Plastic

I typed:

$ LD_LIBRARY_PATH=/root/sqlite/sqlite-autoconf-3070400/.libs:/usr/lib:/root/plastic/server: mono plasticd.exe --console

And it … started up!

But then I connected from another machine and got a beautiful zlib related error. Why? Because Plastic wasn’t correctly loading zlib, so I did the following “fix” (from the server’s path):

$ ln -s /usr/lib/libz.so.1 libz.so

And then I restarted and everything worked!

Ideas

Well, I really love the idea of the “pluggable Plastic SCM server”. I’m using this one as a “spare mirror server” where I automatically push my changes from my laptop on checkin. The “plug” doesn’t have a lot of “disk space” (flash) but an external card can be plugged in or even an external hard drive. Or, even better, I’ll give it a try connecting the Plastic SCM server on it to an external MySQL database… Cool, isn’t it? I mean, for $99 you can have a really cheap mirror server (unless you’re a team with 100 developers or more but, hey!, then don’t be so cheap and buy a real backup!! :P)

Welcome to the jungle!

Note to readers: I strongly recommend reading this post while listening this.

And now... for those about to Git… we salute you! We’ve just released GitJungle, a small, beautiful Git repository browser using our Plastic SCM Branch Explorer (BrEx) visualization technology that basically lets you look at your Git repo from… well, a different angle.

How to download it

Simply go to our just released labs page, read a little bit more about it and then download the binaries (remember you will need Mono installed if you’re a Linux or Mac OS X user).

How to use it

I feel I don’t have to explain you how to clone a git repo but for the sake of completeness here are the instructions to view a repo from GitJungle:

$ git clone https://github.com/jquery/jquery.git
$ cd jquery.git
$ gitjungle .

And you get the beautiful graphics!!

Action not words!

Watch it here:

Warning - experiment zone ahead!

We've just released the GitJungle beta! It's an experiment, it looks cool, it's usable, but it's not free of issues. If you find any… tell us!

We've also used the same core technology behind the Plastic Branch Explorer, which shows history in a horizontal way instead of the vertical way GitK and other UIs use. Suggestions, hard critics and applauses are welcome!

Why are we releasing a Git tool?

We develop and sell Plastic SCM, the most powerful commercial DVCS to date, the one with the best visualizations, multiple database backends, integrated ACL security, superior branching and merging support… ok, let's cut the marketing speech!!

Yes, we do focus on Plastic. However, developing GitJungle only took us a few days so, why not share it?

But, answering the question - we're working on the next version of Plastic SCM and our goal is to make it more interoperable than ever, and two-way synchronization with Git will be one of the key features there.

Also, Plastic SCM is a DVCS for companies and Git is totally focused on OSS projects, so why not collaborate? Git is teaching branching and merging concepts. Also, it’s educating the entire world about distributed development. This is fantastic for Plastic since we can expand and elaborate on these same concepts and practices while at the same time release a tool for software development companies based on these concepts (note: no, Plastic is not based on Git, we had a lot of hard work developing our own core, our own database layer, merge algorithms, security and all the funny things!).

Plastic Themes

Today I'll come up with a small tip and no, it won't be related to branching, merging, replicas or patterns from the Linux kernel... promised!

An easy one for a Thursday, cool?

Ok, I'd love to have something as cool as the Chrome Theme Gallery but let's start small: do you know your current Plastic SCM GUI client is able to change the top banner so you can customize it and look cooler than any of your colleagues?

Look, suppose you want to give your GUI a more Christmas-time style:

Cool, isn't it?

Ok, in order to change your banner:

Create a beautiful png image (500x56 aprox)

Save it as banner.png at your Plastic client location

Restart the Plastic GUI and... you're done!

In case you want to give a try to the Christmas banner, just download this one:

And now a quick look at my own private banner gallery... ;)

Well, I know you're all very busy "pros" doing important stuff with Plastic but... maybe you can give it a try, or even better, design and share your own!! :)

Enjoy!

DVCS for everyone

Or, an illustrated guide to DVCS...

As you’ve probably realized, I’ve started writing a series of blog posts, trying to be as “educational” as possible, and covering topics that range from the history of SCM to branching patterns to the way in which the folks working on the Linux kernel make the best use of branching patterns.

My challenge for today is to try to turn the distributed development tiger into a friendly cat, unable to scare anyone. I know a good fraction of the readers are not really scared of DVCS at all (you Git, Hg, Plastic and Bazaar coders out there!) but since we released our free version one month ago I receive more and more emails from people saying things like “hey, yes, I need better branching and merging but… what’s all this noise about being distributed?”.

So here goes, I’ll try to give you a very easy explanation.

Version control scenarios

The main scenario you’ve been using while getting your hands dirty with Subversion, CVS, Perforce, Team Foundation Server or any of the beautiful version control systems out there is something like the following:

One server handling version control and a bunch of coders “checking in” to it. Easy and comfortable, isn't it?

Then you’ve heard of “distributed development” at places like github.com or at any of the open source projects that have migrated away from Subversion to Git during the last two years (like Ruby or Mono, just to mention a couple).

If you’re a hard core OSS guy, you probably don’t have doubts about what it looks like, but if you’re working in a different environment (maybe small companies, corporations with tight rules and so on) maybe it is not so clear. The first idea that comes to my mind is something like the following:

The big change is that instead of having a central server, now everyone is “running his own version control system” (whether it is a real server or just a .git directory sitting on your working copy is not really important at this stage) and exchanging commits (checkins) in a peer-to-peer way. If you want to, you can unplug from the network, leaving all those internet connection and speed issues behind. (Yes, I know is 2010 but we developers hate waiting and speed is never enough for us, is it?)
But, for the more “centralized-all-under-control” of you out there… I bet this will look like a total mess! I hear you crying “what are you talking about? No central location? Are you crazy?”.

Well, give me a second. Pure DVCS is about … well, about being totally distributed. But reality is a little bit different, so behind the DVCS buzz we all end up having a “central copy” somewhere (or a “master copy” if you prefer). Kernel developers rely on Linus having the “real thing” and the rest of open source projects… well, rely on github.com or something similar, as the following figure shows:

So… don’t panic! There will be a master copy of your beloved source code!

Developers can continue exchanging modifications in a peer-to-peer way, but at the end of the day they’ll be pushing their changes to the central location.

In fact, if you think about it, the different “servers” around won’t be exact copies of each other (not required at least) but the important stuff will be safely stored on the master and replicated among the “developers” for greater safety. (An experimental branch will be only on your computer, or maybe shared by one of your colleagues. But the changes for 3.0 release will be shared by everyone and stored on the master server.)

Networking is key

If you look at the centralized vs distributed scenarios, you’ll clearly see there’s a big difference in terms of the networks where they operate. Centralized is great on LANs, speed is high, latency is low and…well, everything is great with a gigabit-per-second cable plugged to your laptop, isn’t it?

Distributed development grew up because developers always need to work faster than the available network supports. Face it, working against a local repository on your machine is faster than accessing an office server, whether it’s LAN-based or Internet-based.

(There are a bunch of other reasons, too, basically related to branching and merging as I always try to explain, but, ok, speed plays its role.)

Don’t let them fool you...

You know what marketers do best… yes, try to fool all of us ;). I hope none of my marketing friends is listening but, you know, nowadays “distributed development” is a big word and everyone is trying to hop aboard the “distributed ship”.

Let me explain: there are a few truly distributed version control systems out there: Git, Mercurial, Bazaar, Darcs from the Open Source world (yes, I know I’m missing your favorite one, I always do... ); and BitKeeper and Plastic SCM in the commercial dimension. (My beloved Plastic can work in centralized mode too… hey, yes, we’re flexible.). Period.

But, “distributed” is cool, so a guy from the marketing department at company X stands up and says “we’re distributed too” without even changing a line of code of their ancient system. And I find myself having to explain why my system is distributed and the other is not… crazy!

Well, a picture is worth a thousand words:

If you take a centralized system and make it listen on a TCP port for clients connecting over the Internet… it is still a centralized system! Period. Ok, I feel better now.

Multi-site development

Well, some of you are probably thinking now “God! I just wanted to link some offices together, what is this guy talking about?”.

And if you’re thinking that… you’ve probably heard about “multi-site”, haven’t you? Remember the extremely expensive ClearCase Multi-Site functionality? Wasn’t it great? Well, I’ve to admit I’d like to be able to charge as much as Rational did for it but, you know, we’re not in the 90s anymore. What good-old CC was able to do for a fortune is now available, for free or at a moderate cost.

If you’ve got several teams working on different sites, then you’re most likely used to the following picture:

Just to clarify: the “cloud” is “The Internet” not a super-cool cloud computing thing.

Well, here are the challenges: while developers at “Site A” enjoy the full speed of their LAN connection to their central server, the developers at “Site B” are jealous because they must access the server using slower connections, theyhave to wait… (and to make things even more dramatic, I drew the diagram using single-monitor desks for the folks at Site B… :D).

Unless the two sites are connected by some sort of super-cool-fast connection, this setup will end up causing problems. It happened in the past, it happens today and it will happen tomorrow. And connections, nowadays, never seem to be fast or reliable enough. (ok, now I’m waiting for the comment from some guy at “mega-corp”, saying they have a trillion-bps connection that only costs half a million a year and everything just works. Thanks. Yes, we know you’re sooo rich.)

The good news is that the same “technology” used to create distributed teams over the Internet (DVCS) is available to connect your distant offices and moving the “Site B” developers to the “premier league”.

Each site will have its own “central server” and then communication between sites will only happen when the “central servers” replicate changes back and forth. It can be done on demand, it can be done once a day, or it can be done continuously. The point is that “it can be done”.

Distributed is for you… yes it is!

If you’re still thinking distributed “is not for me”, let me try once more. Suppose you’re working on your centralized team with a centralized server but one day you feel like working from home (or going at the customer’s site to fix this really urgent bug -- you know, the kind of things real coders do). Then you’ll be like the guy in the following picture:

What’s the problem here? Well, you’ll be facing the same “slow-downs” that the folks at “Site B” had. Can you live with it? Ok, fine, but, wouldn’t it be better to use something better?

(Please note I gave you a joystick so you can have some fun while waiting for the SCM to finish pushing bits through the Internet :P).

Even on a centralized team it would be great to have the freedom to go offline sometimes, wouldn’t it? And that’s basically what the next picture is all about:

You’ll end up checking in locally, being able to create branches, check differences, walk the history and so on. And you’ll push changes back to the central server only when you feel like doing it… (maybe while you try the latest GT5 after a long day of work… ok, just kidding!).

Short guide through DVCS essentials

I won’t try to come up with a full description about distributed version control operations because I’ve already done that in the past (check http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html and http://codicesoftware.blogspot.com/2008/07/distributed-software-development.html). But I think is a good idea to wrap up with a quick explanation of the main operations, so that newcomers to distributed feel it is not hard at all.

While the main “version control” operations are “checkin” and then probably “branch and merge”, the main distributed operations are: clone, pull and push. And they’re depicted in the following diagram:

Basically, you start with an empty repository and then clone it from somewhere else.

Then you’d like to get the new changes someone put on the central server, wouldn’t you? You’ll use a “pull” for that.

And finally you’d like to make your changes available on the central server, too (or some peer’s copy). You’ll use “push” for that.

I definitely skipped the funny part here: what happens if two developers made concurrent changes in two “replicas”? For now just consider they’ll be able to fix them before doing a “push” because the system will detect it and ask you to merge the changes. This should be enough until you fully jump into the gory details...

Enjoy.

Plastic SCM Plug-In for Zutubi Pulse CI 2.0.x

This article is written as a guide to setup Plastic SCM version 3.0 with Pulse 2.0.x (x= 48 - 51)
This article is updated and maintained at this link here
We will go step by step through the process to setup Pulse, Plastic SCM and nant.exe to successfully make continues builds.

Installing

Install Zutubi Pulse 2.0.x.

Install NAnt 1.90.

Setup nant.exe to be in the PATH environment.

Install Plastic SCM 3.0

While installing Plastic SCM, remember to choose to install Zutubi' Pulse Plug-In as illustrated in Figure 1.

Figure 1: Plastic SCM zutubi Pulse Plug-in

Choose the Data folder of Pulse as illustrated in Figure 2

Default folder would be: c:\Documents and Settings\user\.pulse2\data

Figure 2: Pulse Data path

After successfully installing the above programs, start Plastic Client and create a workspace.

We will use the default repository that is created with the installer.

Setup the system

Plastic SCM

Copy the Plastic SCM client cionfiguration file client.conf

From:

In Windows XP:

C:\Documents and Settings\<LoggedInUser>\Local Settings\Application Data\plastic

In Windows VISTA / 7:

C:\Users\<LoggedInuser>\AppData\Local\plastic

To:

C:\ProgramFiles\PlasticSCM\client

Pulse

Start Pulse2 log-in and Add new Project. See Figure 3

Figure 3: Pulse add new project

Add new child template as illustrated in Figure 4

Figure 4: Pulse add new child project

Name the project as desired, and push next. See Figure 5

In select SCM Type page, select Plastic SCM, and push next. See Figure 6

Figure 5: Pulse project name

Figure 6: pulse choose Plastic SCM

Insert the Plastic SCM workspace selector into the Pulse template workspace selector box as illustrated in Figure 7.

You can view the selector from the Plastic SCM Client GUI, or from the command line cmd.exe window by executing the following command from within the local
workspace folder: c:\workspaceprj01>cm showselector

Check the configuration from within Pulse, and push next button as illustrated in Figure 7

Figure 7: Pulse workspace selector and check

Select Project Type executable project from the drop down options list and push next. see Figure 8

Figure 8. Pulse project type executable

In the executable field insert nant

Figure 9: Pulse define executable, nant

Figure 10: Successful builds with Pulse and nant through Plastic