Plastic SCM blog

CodeCamp 2009 - Tarragona

2009-10-07T09:30:00.004+02:00

We'll be attending at the next CodeCamp in Tarragona sharing our experiencies on multi-platform development with Mono/.NET. I'll be covering both GUI and server code, and the challenges you might find when running on Mac OS X, Windows and the different Linux flavours. Hope you join!

6 Ways Plastic SCM Branches Are Better

2009-07-15T07:37:00.005+02:00

Here is a list of six ways Plastic SCM branches are just better.

Performance - Plastic branches are fast and will always take the same amount of time to create, no performance degradation over time
Automatic Linking - Branches will automatically link to defects
Code Review - Easy to review changes, even in a specific context such as by defect
Rollback - When your worst nightmare occurs, don't panic, just rollback
Replicate - Distributed teams share branching data
Accessibility - Access branch data through ODBC, even the raw file data

Please watch the 5 minute recording that discusses these 6 items in greater detail.

6 Ways Plastic Branches Are Better

It's Not All Technical: The Million Dollar Raspberry Cheesecake with Chocolate Chip Crust

2009-06-23T16:00:00.007+02:00

I went on a BBQ this weekend and baked a cheesecake for the event. I took a look at a couple recipe's online then went crazy and just sort of whipped up something on my own I thought would be good and it turned out to be tremendous so I thought I would share it with our engineering community here in case anyone also has a sweet tooth for a cheesecake. So good it tastes like a million bucks!

Ingredients:

1.5 cups of sugar
1 teaspoon vanilla
3 8oz packages of cream cheese
3 eggs
4 oz heavy whipping cream
1 cup of dark chocolate chips
1 lb chocolate chip cookie dough
3 6oz packages of fresh raspberries
1 package of gelatin (optional)

Directions: Preheat oven to 350.

The Crust
In a greased 9" springform pan ($10 at local wal-mart) take your 1lb of cookie dough and using your hand smash it flat into the bottom of the pan, spread evenly. Place it in the oven at 350 for 15 minutes. The cookie dough will be still gooey when it comes out and this is OK. Let it cool for 30 minutes, or put it in the fridge to cool for 15.

The Filling
In a mixing bowl add 1 cup of sugar and the 3 packages of cream cheese. Stir together while adding 1 egg at a time making sure each egg is stirred well into the cream cheese before adding the next one. Add the vanilla and heavy cream and continue to stir until it starts looking lusciously smooth.

The Topping
Add 12oz of raspberries (2 of the 3 packages) to a blender with the remaining 1/2 cup of sugar and liquefy into a puree.

Optional
You can mix up a packet of plain gelatin in 1 cup boiling water and put 1/2 in the cheescake batter and 1/2 in the raspberry puree. It helps makes the cheesecake more firm.

Assembly
Pour 1/2 of the creamcheese batter into the springform pan. Then add the 1 cup of dark chocolate chocolate chips spread around pretty good. Then add the remaining creamcheese over the chips.

Pour some of the raspberry topping on top of the cheesecake. Not too much, perhaps 1/4 cup, dripping around the top of the cheesecake and use a knife or something to swirl it into the top of the cheesecake (a chopstick or skewer works well too).

Put the rest of the raspberry puree sauce into a bowl or plastic container and throw it in the fridge to chill.

Pop the cheesecake in the oven at 350 for 60 minutes. After you take it out run a knife around the edges and then let it cool for at least an hour. Place the cheesecake in the fridge and let it cool for at least 4 hours.

Serving
To serve the cheesecake take it out of the springform pan and remove it from bottom plate using a plastic spatula (so as not to damage the pan) it should pop right off but be careful and work around the edges. Put the cheesecake on a serving dish and ring the remaning packet of raspberries around the cheesecake.

Take out the remaining raspberry puree sauce and when you plate a slice of cheesecake put 1-2 spoonfools of puree on top and 1-2 more around the cheesecake.

Conclusions
Deliciousness...fattening too, but totally worth it :) the special thing is the cookie dough crust which really makes it one of the best deserts ever.

Sorry no pictures, the cheesecake was eaten before I thought to blog about it. But it would look something like this except with raspberries.

Parallel Development With Plastic SCM

2009-06-12T07:32:00.004+02:00

Over the years I have worked with many SCM tools and they all say they support parallel development but they all do it in very different ways with all kinds of strategies and best practices that vary not only from system to system but also from situation to situation. This is one of the reasons why the Appleton/Berczuk book on branching patterns is so important, so that SCM admins can determine how best to implement a branching strategy to support their ideal development needs in the given enviroment.

With that in mind I've put together a 30 minute video to detail how we recommend doing things with Plastic. The first 15 minute talks in general about parallel development and what some of the pro's and con's are while the second 15 minutes is an example demonstrate of how we recommend using Plastic SCM to implement a simple yet effective parallel development environment. I focus on workflow and best practices while also incorporating some additional useful tools like CruiseControl, NUnit, TestComplete and Jira to help facilitate the process.

Here is the agenda for the video:

Define the problems of serial development
Benefits of parallel versus serial development
Problems with parallel development
How to eliminate or lessen the problems
Keys to effectiveness
Demonstration of key points in action

I've also added a link to the PPT I created for the presentation.

Link to video: http://www.plasticscm.com/demos/paralleldevmovie/Bparalleldev.htm
Link to PPT: http://www.plasticscm.com/demos/paralleldevmovie/BetterDevThroughBranching.ppt

Plastic SCM & PowerBuilder installation guide

2009-05-06T13:00:00.009+02:00

This post describes how to configure PowerBuilder environment to use Plastic SCM as the source code control provider. It assumes the Plastic SCM SCC Plug-in is installed and that your client machine can communicate with the Plastic SCM server.

From Plastic SCM side
You have to change the Plastic SCM preferences before start working with PowerBuilder. You must go to Plastic preferences, then click in the "Other options" tab, and enable the option:

Compare file contents instead of using timestamp for 'quick diff'.

From PowerBuilder side

In order to bind a PowerBuilder workspace with a Plastic SCM one, you must rigth click on the PowerBuilder workspace and then on properties menu option. Then, select the tab "Source control" and you will see a screen like the following one. Select Plastic PLUGIN as Source Control System.

Also you must enable the following options:

Perform diff on status update
Supress prompts to overwrite read-only files

Performance considerations

By default PowerBuilder calls to the SCC provider with file packages. The default value is 25, so if you want to checkin 100 files, PowerBuilder will call the SCC provider 4 times, and will create 4 different changesets.

This is a behavior that we want to avoid, due to our checkin operation being atomic. This value can be changed in the PowerBuilder configuration file (pb.ini), that is placed in the PowerBuilder root installation folder, by default:

c:\Program Files\Sybase\PowerBuilder\pb.ini

You must add the following parameter in the Library section:

SccMaxArraySize=X, being X the number of files per SCC call. A good value could be 5000.

Now Plastic SCM and PowerBuilder are configured to start working. You can take a look at the PowerBuilder documentation about SCC tasks here

Self documented development through inch-pebble checkins

2009-05-01T21:05:00.003+02:00

Developers hate writing documentation. But when you find a weird bug or need to understand why a certain change was done, then you wish you had proper documentation. The problem seems hard to solve. Good comments can help and techniques like diff debugging and proper code review tools can help too. But what every developer does on a regular basis is checking in code to his repository. What if the way in which you check in could help self documenting the code?

Side note: I find the technique I describe here not only good for self documenting changes but also to capture the way in which lead programmers work in such a way it can be used to teach the newcomers...

Read more...

Finding who’s to blame – Plastic SCM annotate

2009-04-09T13:25:00.017+02:00

One of the less known features in Plastic SCM is its ability to track changes on a line basis using the blame (or annotate) command.
I’m going to explain how to use the cm blame | cm annotate command (actually blame and annotate are aliases to the same cm command), and how it can help you identifying changes.
Let’s start with a very simple file with a few lines of code like the one below.

And then let’s start making changes in the main branch and in two new more branches, until we’ve a tree like the one at the following image.

At any given point in time we can run a blame command to a given file and identify where the changes came from. Let’s see how Plastic SCM can identify it looking at the next diagram.

What Plastic does is climb the version tree upwards from the starting point you’ve at your workspace. If you start up at revision 1 on /main, changes will only come from this revision itself or the one immediately up. Something different will be displayed if you start from rev 2 at /main/task001.

The good thing is that the Plastic annotate/blame command is not only restricted to climbing the tree up through the branch, but it can also go through the other branches as soon as there are available paths (created when you merge branches), so properly identifying where changes come from.

After merging the two branches, the new revision 3 at /main, will have contributors not only from its previous revs on the branch, but from the other branches. The interesting point to highlight is that changes are not identified as coming from revs 2 and 3, but from the correct ones in the branches.
Considering Plastic SCM promotes using branches as much as possible, and linking branches to tasks/issues/defects on your favorite project management/issue tracking system, you’ll be able to track where exactly changes came from.
Let’s now go through a step by step example, using the command line, to explain how annotate behaves in a real scenario.


> cm mkwk wk01 .
Workspace wk01 has been correctly created

> cm co .
The selected items are about to be checked out. Please wait ...
Item . was correctly checked out

> cm add hostname.cs
The selected items are about to be added. Please wait ...
Item hostname.cs was correctly added

> cm ci hostname.cs . -c="initial commit"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Checking in d:\data\code\testwkspaces\wk01 ... Done
Created changeset cs:1@br:/main@rep:default@repserver:BEARDTONGUE:8084

Let's create a couple of smart branches from the CLI


> cm mkbr br:/main/task001

> cm sbb br:/main/task001 cs:1
A new base has been set for the branch br:/main/task001. 
A checkpoint changeset cs:2@rep:default@repserver:localhost:8084 has been created

> cm mkbr br:/main/task002

> cm sbb br:/main/task002 cs:1
A new base has been set for the branch br:/main/task002. 
A checkpoint changeset cs:3@rep:default@repserver:localhost:8084 has been created

And now make a change on the main branch.

I'll be using a co/ci cycle, but as you'll see below, you can follow a commit-only cycle with Plastic too.


> cm co hostname.cs
The selected items are about to be checked out. Please wait ...
Item hostname.cs was correctly checked out

> // edit hostname.cs

> cm ci hostname.cs -c="class name changed"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:4@br:/main@rep:default@repserver:BEARDTONGUE:8084

Now switch to task001.


> cm stb br:/main/task001
> cm co hostname.cs
The selected items are about to be checked out. Please wait ...
Item hostname.cs was correctly checked out
> // edit hostname.cs
> cm ci hostname.cs -c="variable name changed"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:5@br:/main/task001@rep:default@repserver:BEARDTONGUE:8084

And now I'll show a ci only cycle


> // edit hostname.cs
> cm ci hostname.cs -c="another var name changed"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:6@br:/main/task001@rep:default@repserver:BEARDTONGUE:8084

> // edit hostname.cs

> cm ci hostname.cs -c="more info printed"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:7@br:/main/task001@rep:default@repserver:BEARDTONGUE:8084

Now onto task002


> cm stb br:/main/task002
> // edit hostname.cs
> cm ci hostname.cs -c="usage controlled"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:8@br:/main/task002@rep:default@repserver:BEARDTONGUE:8084
> // edit hostname.cs
> cm ci hostname.cs -c="usage with info"
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:9@br:/main/task002@rep:default@repserver:BEARDTONGUE:8084

Let's go back to br:/main and run the annotate before merging.


> cm stb br:/main

> cm blame hostname.cs
pablo br:/main#0 using System;
pablo br:/main#0 using System.Net;
pablo br:/main#0
pablo br:/main#0 namespace gethostname
pablo br:/main#0 {
pablo br:/main#1     class GetHostNameTestProgram
pablo br:/main#0     {
pablo br:/main#0         [STAThread]
pablo br:/main#0         static void Main(string[] args)
pablo br:/main#0         {
pablo br:/main#0             string howtogeek = args[0];
pablo br:/main#0             IPHostEntry hentry = Dns.GetHostByName(howtogeek);
pablo br:/main#0
pablo br:/main#0             foreach (IPAddress theaddress in hentry.AddressList)
pablo br:/main#0             {
pablo br:/main#0                 Console.WriteLine(theaddress.ToString());
pablo br:/main#0             }
pablo br:/main#0         }
pablo br:/main#0     }
pablo br:/main#0 }

And now on the branches:


> cm stb br:/main/task001
> cm blame hostname.cs
pablo br:/main#0     using System;
pablo br:/main#0     using System.Net;
pablo br:/main#0
pablo br:/main#0     namespace gethostname
pablo br:/main#0     {
pablo br:/main#0         class Class1
pablo br:/main#0         {
pablo br:/main#0             [STAThread]
pablo br:/main#0             static void Main(string[] args)
pablo br:/main#0             {
pablo br:/main/task001#0         string hostName = args[0];
pablo br:/main/task001#0         IPHostEntry hentry = Dns.GetHostByName(hostName);
pablo br:/main#0
pablo br:/main/task001#2         Console.WriteLine("Addresses: {0}", hostName);
pablo br:/main/task001#1         foreach (IPAddress address in hentry.AddressList)
pablo br:/main#0                 {
pablo br:/main/task001#1             Console.WriteLine(address.ToString());
pablo br:/main#0                 }
pablo br:/main#0             }
pablo br:/main#0         }
pablo br:/main#0    }

> cm stb br:/main/task002

> cm annotate hostname.cs
pablo br:/main#0   using System;
pablo br:/main#0   using System.Net;
pablo br:/main#0
pablo br:/main#0   namespace gethostname
pablo br:/main#0   {
pablo br:/main#0       class Class1
pablo br:/main#0       {
pablo br:/main#0           [STAThread]
pablo br:/main#0           static void Main(string[] args)
pablo br:/main#0           {
pablo br:/main/task002#0       if( args.Lenght == 0 )
pablo br:/main/task002#0       {
pablo br:/main/task002#1           Console.WriteLine("usage: hostname name");
pablo br:/main/task002#1           Console.WriteLine("\tname of your host");
pablo br:/main/task002#0           return;
pablo br:/main/task002#0       }
pablo br:/main/task002#0
pablo br:/main#0               string howtogeek = args[0];
pablo br:/main#0               IPHostEntry hentry = Dns.GetHostByName(howtogeek);
pablo br:/main#0
pablo br:/main#0               foreach (IPAddress theaddress in hentry.AddressList)
pablo br:/main#0               {
pablo br:/main#0                 Console.WriteLine(theaddress.ToString());
pablo br:/main#0               }
pablo br:/main#0            }
pablo br:/main#0       }
pablo br:/main#0   }

Let's merge the branches back to main:


> cm stb br:/main
Plastic is updating your workspace. Wait a moment, please ...
Copied hostname.cs

> cm merge br:/main/task001 --merge
Merge needed on item hostname.cs 
from br:/main/task001#2 
to br:/main#1 base br:/main#0. 
Changed by both contributors.
Merging hostname.cs
Merge done

> cm ci hostname.cs
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:10@br:/main@rep:default@repserver:BEARDTONGUE:8084

And blame:


> cm blame hostname.cs
pablo br:/main#0     using System;
pablo br:/main#0     using System.Net;
pablo br:/main#0
pablo br:/main#0     namespace gethostname
pablo br:/main#0     {
pablo br:/main#1         class GetHostNameTestProgram
pablo br:/main#0         {
pablo br:/main#0             [STAThread]
pablo br:/main#0             static void Main(string[] args)
pablo br:/main#0             {
pablo br:/main/task001#0         string hostName = args[0];
pablo br:/main/task001#0         IPHostEntry hentry = Dns.GetHostByName(hostName);
pablo br:/main#0
pablo br:/main/task001#2         Console.WriteLine("Addresses: {0}", hostName);
pablo br:/main/task001#1         foreach (IPAddress address in hentry.AddressList)
pablo br:/main#0                 {
pablo br:/main/task001#1             Console.WriteLine(address.ToString());
pablo br:/main#0                 }
pablo br:/main#0             }
pablo br:/main#0         }
pablo br:/main#0     }

Second branch:


> cm merge br:/main/task002 --merge
Merge needed on item hostname.cs 
from br:/main/task002#1 
to br:/main#2 base br:/main#0. 
Changed by both contributors.
Merging hostname.cs
Merge done

> cm ci hostname.cs
The selected items are about to be checked in. Please wait ...
Checking in hostname.cs ... Done
Created changeset cs:11@br:/main@rep:default@repserver:BEARDTONGUE:8084

> cm blame hostname.cs
pablo br:/main#0     using System;
pablo br:/main#0     using System.Net;
pablo br:/main#0
pablo br:/main#0     namespace gethostname
pablo br:/main#0     {
pablo br:/main#1         class GetHostNameTestProgram
pablo br:/main#0         {
pablo br:/main#0             [STAThread]
pablo br:/main#0             static void Main(string[] args)
pablo br:/main#0             {
pablo br:/main/task002#0         if( args.Lenght == 0 )
pablo br:/main/task002#0         {
pablo br:/main/task002#1             Console.WriteLine("usage: hostname name");
pablo br:/main/task002#1             Console.WriteLine("\t name of your host");
pablo br:/main/task002#0             return;
pablo br:/main/task002#0         }
pablo br:/main/task002#0
pablo br:/main/task001#0         string hostName = args[0];
pablo br:/main/task001#0         IPHostEntry hentry = Dns.GetHostByName(hostName);
pablo br:/main#0
pablo br:/main/task001#2         Console.WriteLine("Addresses: {0}", hostName);
pablo br:/main/task001#1         foreach (IPAddress address in hentry.AddressList)
pablo br:/main#0                 {
pablo br:/main/task001#1             Console.WriteLine(address.ToString());
pablo br:/main#0                 }
pablo br:/main#0             }
pablo br:/main#0         }
pablo br:/main#0     }

How does the vtree look?

And finally a graphic explaining the annotate I just showed above.

It's also possible to decorate each line with the comment:


>cm blame hostname.cs --format="'{comment, -24}'{content}"
'initial commit          'using System;
'initial commit          'using System.Net;
'initial commit          '
'initial commit          'namespace gethostname
'initial commit          '{
'class name changed      '  class GetHostNameTestProgram
'initial commit          '  {
'initial commit          '      [STAThread]
'initial commit          '      static void Main(string[] args)
'initial commit          '      {
'usage controlled        '        if( args.Lenght == 0 )
'usage controlled        '        {
'usage with info         '            Console.WriteLine("usage: hostname name");
'usage with info         '            Console.WriteLine("\t name of your host");
'usage controlled        '            return;
'usage controlled        '        }
'usage controlled        '
'variable name changed   '        string hostName = args[0];
'variable name changed   '        IPHostEntry hentry = Dns.GetHostByName(hostName);
'initial commit          '
'more info printed       '        Console.WriteLine("Addresses: {0}", hostName);
'another var name changed'        foreach (IPAddress address in hentry.AddressList)
'initial commit          '        {
'another var name changed'            Console.WriteLine(address.ToString());
'initial commit          '        }
'initial commit          '      }
'initial commit          '  }
'initial commit          '}

Enjoy!

Using Changes app

2009-04-03T07:37:00.011+02:00

As most of us Mac developers will be aware, Xcode comes with FileMerge, but sometimes you just need a little bit extra. I recently came across Changes, here's how to use it with Plastic.

After downloading, install the Terminal Utility to give yourself the command line interface. Then, from within a workspace, you can diff two revisions like so (I'm using BASH):

$ chdiff <(cm cat GameScene.mm#br:/main#1) <(cm cat GameScene.mm#br:/main#LAST)

To get this working from within the Plastic GUI client, we'll need to edit the client.conf file which is located in ~/.plastic/client.conf.

Find the section <DiffTools>, and a few lines down replace the "mergetool" entry with this:

<string>/usr/bin/chdiff "@sourcefile" "@destinationfile"</string>
Restart the Plastic GUI client and diff away.

stackoverflow campaign

2009-04-01T10:30:00.003+02:00

We're running a campaign at stackoverflow, displaying the new collection of funny photos we created for the site.

I've just found a screenshot showing one of the ads at a post talking about responsible advertising at stackoverflow:

There're 3 more (plus one considered too sexy, which we'll keep secret for some time :-P) you can find at the site.

Disintegrating changes with GIT and with Plastic

2009-03-30T21:13:00.004+02:00

I've just published a post explaining how disintegration (or subtractive merge if you prefer) works in GIT and Plastic SCM.

You can find the full article here.

Normally I'd just focus on what we do with Plastic SCM, but since GIT is big among OSS developers (and Monologue readers), I thought it could be good to explain how it works there too.

Enjoy

Merge Without Fear

2009-03-25T18:35:00.006+01:00

Over the years I've talked with many software developers about branching and merging and found there is almost a universal distrust of using branches despite all the benefits that can be provided by branching.

The main source of this distrust really stems from merging. The branching part everyone can handle it is when you go to integrate changes, generate complex software configurations and perform complex merges against a codeline with many contributors that is the source of the problem.

Over the years programmers have developed a mistrust, or worse an outright fear, of merging which is really a result of tools that lack proper branch and merge support. But even with proper merge tracking there is always a fear when doing merges that something will break, something will happen that can not be easily undone and then someone will be left spending hours trying to fix it with the boss screaming over their shoulder the entire time.

This is where Plastic SCM rises above the rest. We have a simple and effective way to handle merges that makes it a fearless operation.

There are two aspects that make the process fearless that I will focus on (there is a third which involves rollbacks which I don't get into here).

1.) You have an opportunity to test the results of your merge before anything gets committed to the database.
2.) You can always undo a merge if the test results are bad.

Plastic SCM already has excellent merge tracking. This means all your merge history is remembered so you don't double merge or unmerge by accident. Merge tracking makes it possible to do merging over time especially with a large number of contributors. What I focus on in the screencast is the aspect of Plastic merging that allows you to build your project, test it, and then cancel the merge or commit it to the SCM repository depending on the results.

Enjoy.

Merge Without Fear Video

Please send feedback to pburma@codicesoftware.com

Test before you run...

2009-03-24T15:09:00.003+01:00

I'm posting to my blog at DDJ a couple of hopefully interesting articles about how we stress test Plastic SCM using NUnit (PNUnit to be exact, our humble contribution to the project) and about 100 machines (750K bogomips!!)

First article is here and the second one here.

Hope you like it.

Setting up a fallback server using replication

2009-03-20T16:13:00.012+01:00

to work under a wide variety of scenarios.

Normally when you think about distributed you inmediately jump into the situation where each developer has his own repository and replicates changes back and forth with his peers or a central location (or the one with highest rank in the meritocracy if you prefer :-P).

But today I'm going to talk about a slightly different set up.

What if you need to have redundant servers so in case one goes down you can inmediately recover and all developers (normally in a big shop) can continue working with the fallback machine?

Well, Plastic has several ways to solve this problem (you know, we're flexible!):

The first one involves taking advantage of one of its supported backends and implement a mirrorer database with MySql or SQL Server. It is adequate when you've seasoned dbas at home, who are already doing the same stuff on a daily basis for their corporate servers.

And the second option, the one I'll be explaining today, relies on the distributed system to implement an equivalent behavior.

The following figure depicts the situation.

Ok, how can we set up this with Plastic?

First you obviously need a couple of servers, one you're already using on a daily basis and then a second one (probably a clone of the first one), also running Plastic. In order to make things easier to understand, the first server will be called dragon and the second one pendergast.

dragon will be hosting the master repository and pendergast a second one, named replica, which will be a clone of master.

Note: needless to say servers could be running on different operating systems and even using different database backends.

Once the servers are up and running, the procedure will be really simple:

Locate which branches to replicate

Replicate them

Run the process repeteadly (e.g. once an hour)

So, how can we identify which branches deserve our attention and have to be replicated? Easy: we need to know where are the changes made since the last replication, don't we?

And, how can we know what changes have been done and where? Look at the changesets view and click on the advanced button, as shown in the following picture.

Plastic SCM supports fully distributed development and hence it is flexible enough

Plastic implements a powerful sql-like query system.

Most of the views in the Plastic GUI retrieve their data from a Plastic query, and changesets view is one of them. So we just have to take a look to the default query to figure out what do we need.

In fact, the detailed process to follow is drawn here, including the replication commands to use.

We will be using a command like the following


$ cm find changesets where date >= ‘2009/03/18  19:30:00’ --format={branch} --nototal

To find changes and:


$ cm replicate br:/main/task00X@master@dragon:9090 replica@pendergast:7074

to replicate.

Here's the ruby code I used for my replication script:


if ARGV.size < 2
    puts "Usage: synchservers srcrepspec dstrepspec"
end

srcrep = ARGV[0]
dstrep = ARGV[1]

# find all changes since last replication (one hour)

date = Time.new - 60*60

branchescommand = sprintf(
    'cm find "changeset where date >= \'%s\'" --format={branch} --nototal on repository \'%s\'',
    date.strftime('%Y/%m/%d %H:%M:%S'), srcrep )

output = `#{branchescommand}`

# build an array of branches

branches = Array.new

output.each { |branch| branches << branch.chomp}

# run removing duplicates

branches.uniq.sort.each { |branch| 
    replicatecmd = sprintf(
        'cm replicate br:%s@%s rep:%s',
        branch, srcrep, dstrep);
    puts replicatecmd
    system(replicatecmd)
}

Easy?

In order to run it you just have to:


$ synchservers.rb master@dragon:6060 replica@pendergast:9090

And include it as a cron or scheduled task.

Enjoy!

Live to merge, merge to live (3 parts out)

2009-03-20T09:53:00.002+01:00

There are already 3 posts out on "live to merge, merge to live" on DDJ's guru blog:

Part I

Part II - Manual conflicts

Part III - Tracking

Hope you find it helpful

SD West 2009

2009-03-17T16:02:00.007+01:00

SD West 2009 is over and we're just back from our trip to San Francisco. It was great to meet developers there and also some of our competitors such us Accurev and Perforce. I actually had a very interesting and friendly talk with Damon Poole, Accurev's CEO, about a number of different business related things.

We had the opportunity to talk with developers about our newest 2.7 release, which grabbed a lot of attention, especially the new distributed capabilities.

It was our first time at SDWest, and it's been a lot of fun. The booth was located just at the entrance of the expo area, so we had lots of visitors. We gave away hundreds of T-shirts (two different designs) most of them during the first day (until we almost run out of them) in just a few minutes. (We'll have to bring more next year!)

We also gave away Plastic License Cards, a collection of four different pictures which included 2 free Plastic SCM Professional licenses, I don't remember the exact number anymore, but we almost run out of them too.

Wednesday evening we attended the Jolt Awards ceremony which was an exciting event. This year was the first time we submitted Plastic SCM to the Jolts, and we were more than happy to se how it was selected as one of the finalists among a number of SCM systems, so our mission was accomplished, but it was good to see how Open Make finally got the Jolt, after several years on the list. (Note to self: publish a tutorial about OpenMake/Plastic integration asap).

So, we're eager to go back to Santa Clara next year and hopefully unveil there the upcoming Plastic SCM 3.0 :-)

Plastic is a Jolt Finalist!

2008-12-31T11:58:00.002+01:00

Yes, Jolt Award 2009 Finalists have been announced and... Plastic SCM is one of them!!

Plastic is one of the 5 tools selected for the Change and Configuration Management category, together with systems like Accurev, OpenMake or TeamCity to mention a few.

Codice is a very young company, so just being on the list is great for us. The Jolt nomination has been an incredible Christmas present for the team.

We work hard to make Plastic the best version control system out there, and we know there's always lots of work to do, lots of competitors (bigger than us) doing a very good job, so is nice to see how Plastic is making its way through.

Plastikers, enjoy this and... happy 2009!

Merge to live, live to merge

2008-12-31T11:50:00.002+01:00

I've just published a new post explaining the basics of merging on the DDJ guru's blog.

I'm writing a series or articles describing the very basics of merging since I still find people afraid of merging (and lock-prone) very often.

Here are the links:

Part I

Part II

Stay tuned!

Plastic on Solaris 10

2008-12-24T02:27:00.010+01:00

Well, it's been a *real* pain to build mono on Solaris 10!! Compared to this building in OpenSolaris was veeeery easy.

I'll try to repeat the process in the coming days and try to create a detailed guide. Building libgdiplus was specially painful, but I guess I've been doing something wrong (I hope!).

And then, finally, a real "back to the future" screenshot here:

I used to love this beauty about ten years ago, and now it doesn't look that nice anymore (although I still like it :-D).

And another screenshot, this time with a most modern look & feel:

I love Solaris, so being able to run the Plastic GUI there is some sort of Christmas present for me... :-) I love Solaris since I started reading the Jim Mauro articles about threading and so on, and later his great book about internals.

But, to be honest, after being using Mac OS X (10.4 & 10.5) for the last three years (and almost on a daily basis during the last weeks) it's clear there's a message for the Solaris folks out there: hire a graphics designer! (ok, if you have one... fire him and hire a new one!!)

So, what's next? Ok, there's only one OS I like better than Solaris... OpenBSD! So stay tuned..

OpenSolaris and MWF

2008-12-23T13:51:00.004+01:00

Finally! We've Plastic SCM 2.7 GUI running on OpenSolaris! You know Plastic GUI is heavily based on Mono WinForms, don't you? Ok, then check what Mono WinForms can do...

Click on the image or here to watch a screencast and see it in action.

Enjoy!

White testing Plastic

2008-12-06T22:32:00.003+01:00

Ever heard of White? You should.

White is a promising testing framework based on the UI Automation APIs which enables you to write tests in C# (or your favorite .NET language).

Why is it interesting? I think there're several reasons but, for me, the main ones are:

Developers can write GUI tests as they'd write unit tests: from their own development environment, in their language of choice. It makes a huge difference.

Tests can be integrated with NUnit, or, in our case, with PNUnit, the distributed extension to NUnit which has been integrated in NUnit 2.5 (we run our test suites on several variations of Linux, Windows and MacOS (including x86 and PPC)).

What to see it in action? Watch the following screencast of White testing Plastic:

Distributed development with Plastic

2008-12-04T14:41:00.003+01:00

Distributed development has been introduced in Plastic in release 2.5, but now with 2.7 we make it even easier to use because it jumps from the command line to the GUI.

The main difference is that now replicating branching branches back and forth is just a click away although good-ol CLI scripting still allows you to rapidly automate stuff using the cm replicate command.

This screencast explains in detail how a simple distributed working workflow can work with Plastic.

You can always check the distributed development user's guide for more information, but watching the video will be probably faster... :-)

Announcing Plastic 2.7

2008-11-27T11:34:00.005+01:00

We're proud to announce a brand new Plastic release: 2.7. It comes with a big number of improvements, new functionalities and fixes.

Check the release notes here:

http://www.plasticscm.com/opdownloads2/opreleasenotes2.aspx

What's new on 2.7. There's a huge list but just to mention a few:

Distributed development support on the GUI: now all replication operations can be done from the GUI and not only the CLI. It makes distributed development easier than ever. You can replicate branches back and forth with just a few clicks.

Visual Studio 2005 & 2008 AddIn: all Plastic SCM features are now included inside Visual Studio 2005 and higher. You can not only run the regular operations but also create branches, workspaces, run merges, inspect changes, display the branch explorer and so on. http://www.plasticscm.com/demos/vsextended/vsextended.html

Enhanced Eclipse integration: we always try to focus on Eclipse users and 2.7 brings a number of new features such us: the ability to create branches, run merges, smart branch support and the new changesets view.

Xmerge: yes, finally the "cross merge" is out! What's Xmerge? It's a new step ahead on merge tool development: it's not magic (not yet at least) but it will help you dealing with code moved and modified in parallel on the same file. You'll be able to select the conflicting area and merge moved code with the help of Plastic merge tool. Take a look at http://codicesoftware.blogspot.com/2008/08/xmerge-tool-to-handle-refactors.html and see how it can help dealing with refactors. It is just the first step so expect much more on the coming releases.

We've also redesigned the screencast page, so if you want to see Plastic in action just take a look here: http://www.plasticscm.com/xschannel.aspx

There's a highlights video http://www.plasticscm.com/demos/plastic27short/3.html and several other interesting ones like an introduction to distributed development using Plastic: http://www.plasticscm.com/demos/distributed_intro/distributed_intro.html

C# Evaluator

2008-11-06T09:47:00.002+01:00

A month ago or so one of the most exciting new feaures of the upcoming Mono 2.2 was introduced: the C# Evaluator. (Although now, with the new Mono.SIMD, static compilation and so on, I'm not sure which one is the most exciting piece anymore?)

Since then I wanted to blog about it to share my thoughts about the possibilities of this new piece of software. For the folks being around for a while C# Evaluator probably reminded them the old Windows Scripting Host which allowed us programmers to embed powerful scripting in our applications. Now, having C# as a scripting language for your own customization purposes opens new paths for innovation and great ideas.

I'm really eager to include some powerful C# scripting inside Plastic , probably in order to create more powerful workspace selector rules or something like that.

But first I'll try to tell a little bit about how to play with the C# eval in order to learn how it works. First thing is to build and set up the latest mono, so let's start there.

Setting up a 2.2 environment

Once Mono 2.0 was releases I set up a OpenSuse 11 box to play around with it. I was having some trouble building 2.0 on Solaris and OpenSolaris, so having the chance to download and build on Linux was a real pleasure.

So, first I installed OpenSuse 11 with the development tools that can be configured during the installation process. Then I set up 2.0 downloading it from the official Mono repository (check the mono website and go to downloads).

And then I just downloaded trunk from the mono repos


$ svn co svn://anonsvn.mono-project.com/source/trunk/mono
$ svn co svn://anonsvn.mono-project.com/source/trunk/mcs
$ svn co svn://anonsvn.mono-project.com/source/trunk/libgdiplus

And launch the build process


$ autogen.sh --prefix=/home/pablo/monobin
$ make
$ make install

Note I generated the binaries on my home dir.

I built everything under /home/pablo/monobin because I still wanted to use official mono 2.0 for regular operations and 2.2 just for testing and development purposes.

In order to use the newly compiled mono 2.2 you just have to set up your MONO_PATH env var:


$ export MONO_PATH=/home/pablo/monobin
$ export PATH=/home/pablo/monobin/bin/:$PATH

Enter the C# Evaluator
Miguel introduced a sample in his blog post (http://tirania.org/blog/archive/2008/Sep-10.html) but he didn't tell how to perform an action I consider very interesting: making the script interact with your own classes. (Of course I bet he didn't do that because it is more than obvious for most of the people out there, but I hope you still find this sample interesting).

So, as I said, the real beauty of introducing some scripting in your application is not running simple calculations, but making the script interact with your own internal classes or ad-hoc APIs, right?

So, here you can find some very simple source code (the simplest) showing you how to interact with your own assembly. Note I'm adding the current assembly to the script references, and also introducing a using sentence.


using Mono.CSharp;
using System.Reflection;
using System;

namespace CSharpEvalTest
{
  public class Test
  {
    public static int val = 1000;

    static void Main(string [] args)
    {
      Evaluator.Run(
        "using System; using CSharpEvalTest;");

      Evaluator.ReferenceAssembly(
        Assembly.GetExecutingAssembly());

      Evaluator.Run("Test.val = 120;");
      Console.WriteLine("val is {0}", val);
    }
  }
}

How to build the code?

Easy:


$ gmcs test.cs -r:gmcs.exe

And you're done.

Remember I've modified both PATH (to get the new gmcs) and MONO_PATH!

Branching Basics Video

2008-11-03T13:33:00.001+01:00

We just finished a new recording on branching basics with Plastic SCM. This part of an ongoing effort to publish a video every week or every other week that documents and outlines Plastic SCM features.

The purpose of this video is to introduce users to branching with Plastic at a novice level.

Click For Full Screen Video

Plastic Quick Start Video

2008-11-03T13:30:00.003+01:00

Here is a video just recorded to walk users through some of the basic functionality and usability features available with Plastic SCM. This video picks up right after the point of installation and has a running time of 9:36.

Click for Full Screen Video