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.
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
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!
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.
Running Plastic on Ubuntu
What would you think is harder to do? Run a .NET Client/Server application through mono on Linux or install Ubuntu on Microsoft's Virtual PC?The answer is installing Ubuntu (or any Linux) on Virtual PC. It happens to be pretty difficult and there are a lot of blogs, user forums, and web sites that have helpful information on how to get it done. Using a combination of about 3 different sites I was able to get it running, but was never able to change my resolution to past 800x600.
I like to use VPC over a VMWare player image because I like to have control over the installation itself which requires purchasing VMWare instead of using the free VPC. It only cost me a migraine. I do like VMWare, I just like managing my own installs more.
Running Plastic SCM on Ubuntu is rather easy but there are a few system requirements that need to be satisfied before both the client and server can run. First Plastic requires mono. The vanilla desktop install of Ubuntu 8.0.4.1 happens to include mono by default so no problem there. Plastic also required FireBird which is not a default element install on Ubuntu and probably not a default package on most Linux installations.
FireBird is a cross-platform RDBMS, you may remember it as a form of InterBase that Borland open sourced a number of years ago. If you visit the FireBird web site you will find download packages for Linux but it is much, much easier to use the built in Synaptic package manager for Ubuntu. If the package list is up to date you can do a search for "FireBird" and download and install this package. The great thing about package managers like Synaptic is it includes all the dependencies automatically and there where several that I needed to run FireBird.
After the FireBird server and it's dependencies are installed then I run the Plastic installer on Linux. The last step in the installation will ask if you want to run and configure Plastic. These options are enabled by default and if you keep them on then the Plastic server will start for you automatically (it will also start after a reboot).
The Plastic install on Linux includes a bunch of Windows dll's and exe's but we do not need to worry about these files. Included in the install are some handy shell scripts that will launch the Plastic executable with the proper mono arguments. The client script is called simply "plastic" so to launch the client use the command:
/opt/PlasticSCM/client/plastic
That is using the default location of course, and this same path can be used when setting up a desktop icon.
Oh and if you want to run Ubuntu on VPC then try here for Fedora users try here.
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.
Firebird is faster than filesystem for blob storage!
To blob or not to blob... good question!I guess if you develop data intensive applications dealing with large files at some point, you've thought about it at least once: should I put my data files inside the database or should I write them directly to disk?
There are a number of interesting links to consider:
Just google it and you'll get a big number of entries.
Ok, so here's my point:
storing files in Firebird is faster than writing the same files on the filesystem!
Which is pretty good for all the structured storage true believers, I think.
Ok, let's take a look at the figures, here's my program which is able to recursively take the files in a directory, split them in 4Mb chunks and write them to another directory or a firebird database.
For my test I used a tree with:
And here's the output, first writing to Firebird and then to a filesystem.
>writedir d:\testcode d:\repodata fb
Total time 27669 ms
>writedir d:\testcode d:\repodata
Total time 40378 ms
A hash is calculated for each file chunk which also takes some time.
What I believe is pretty interesting is how writing to a Firebird database (which stores small files saving disk space since it only uses one single file!) is actually faster than dumping the same content to disk!!
Of course, there are a number of situations where high-perf software (including SCM) can benefit from using a FS instead of a database, but blob storage (with Firebird :-P) is not one of them...
You can find the full source code here.
Enjoy!
Side notes
Subscribe to:
Posts (Atom)
2 comentarios: