Disintegrating changes with GIT and with Plastic

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

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...

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

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)

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

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 :-)