Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Continuous Replication Between 2 Sites

Thursday, September 18, 2008 Pat Burma 0 Comments

Continuous replication between 2 sites means as changes are committed to a branch those changes are replicated to another remote server. This is done on demand using triggers and is made possible using the "cm replicate" command.

Reason for Replication?

1.) Collaboration - This means sharing code between multiple sites. Teams operating in two or more locations such as a Client team and a Server team can more rapidly share updates between locations.
2.) Distributed Development - Geographically distributed offices or offshore/contracted sites can quickly share, push and pull, updates between one another. Individual users and offices can synch up to one another.
3.) Reporting Server - Setup a separate server with the same change history for reporting or integration services into 3rd party tools like dashboards or PPM's.
4.) Other? - I'm sure there are other uses for this that I have not even imagined.

How It Works
Replication of this type works by comparing changesets between the source (host) and destination (target) server locations and copying the changesets and associated history (user data, labels, etc) to the destination.

Triggers can be setup to execute server side scripts that run whenever certain events occur like a checkin. The two can work together to support continuous replication.

This type of replication is not meant to replicate all the history in your Plastic database. While it maybe possible to do there are easier database replication features available for backup and rollover support. If you are looking to try for five nine's stability with Plastic then you are better off using standard database services as opposed to replication.

Step By Step

What is needed first is two Plastic servers that can talk to each other. I am going to assume these are in place, but check out the Plastic User Forums if you want to learn about running Plastic on a secured SSL channel.

1.) Site A: Add a check in trigger.

cm maketrigger after-checkin ReplicateToSiteB "C:\Replicate.bat"

2.) Site A: Setup the replication script

Create a file called Replicate.bat on the C:\ drive which contains a line like this (make sure to edit the server and repository values)

cm replicate br:/main@rep:default1@repserver:localhost:8084 rep:default2@repserver:192.168.0.108:8084

3.) Repeat step 1 & 2 at Site B but using the destRepo and destServer values of Site A.

Done. Now just checkin changes and watch as your teams suddenly collaborate like never before!

Pat Burma

0 comentarios:

Subscribe to: Post Comments (Atom)