Thursday, September 18, 2008

Check In Changes using Email

Ever wonder if it was possible to use an SCM tool to check in changes through Email. Guess what? It is! There are many situations where a programmer may want to work on code but may not have direct access to the server. A VPN connection may not be available or just really slow. perhaps you just want to see how cool it is to use Email to manage your source code changes.

How It's Done

Plastic has a replication command which can be used to copy change history from one location to another. This can be done through a direct connection specifying your source server location and your destination server location. But; It is also possible to export a package file and this package file can be moved, copied or Emailed from the source server to the remote server and then imported into the main repository.

What You Will Need

1.) Install Plastic SCM client and server on your laptop, home desktop, or wherever your remote location is going to be.
2.) Use the replicate command to export your /main trunk, or other branches, or make a copy of the Plastic database (*.fdb in your PlasticSCM/server) directory. This step is necessary so you have a Plastic repository that resembles your central repository.
3.) Setup your home server repository using the import package from the central server, or copy in the .fdb files to start off with a copy of your work database. You can also use the replicate commands via VPN or network connection to get this initial step done.

After you have a copy of your repository from work you are ready to go. You can make changes offline, at home, wherever then export those changes and Email them to work where they can be imported by you when you get to the office or by a colleague.

It will be necessary to occasionally update your home server using the same method. You can export changes as a package and email them to yourself at home or if you are using a laptop you can occasionally synchronize your server with your work server using the replicate command (to simplify just save the commands as a batch).

Step By Step

So now your setup with a copy of your work repository and you are mobile. Let's run through the commands and steps to make this happen!

First, its recommended you use a branch at home to make your changes. It's going to be easier to create a package this way. Let's say you create a branch called Bug099 and you check in a bunch of changes and now you want to Email it to Earl in IT who can check it in for you.
Your command will look something like this:

cm replicate br:/main/Bug099@rep:default2@repserver:localhost:8084 --package=C:\bug099

Zip up the file at C:\bug099 and email it to Earl in IT. Once Earl receives the Email from you he can unzip the file to C:\bug099 and run this command to import the changes you made.

cm replicate rep:default2@repserver:localhost:8084 --import=C:\bug099

That's all there is too it. You can create a simple one line batch file to Export the package and another to Import the package. The command syntax for each is:

cm replicate srcBranch --package=packagename [--changeset=number]
cm replicate destinationRepos --import=packagename

srcBranch: a full branch spec in form

br:/NAME@rep:REP_NAME@repserver:SERVER_NAME:port

dstRepos: a full repository spec

rep:REP_NAME@repserver:SERVER_NAME:port

It can be a little tricky determining your srcBranch syntax. To verify this open up the Plastic GUI client and on the Branch Explorer right click on your srcBranch and select Permissions. The permissions window will show the full srcBranch path.

In addition to exporting a branch into a package you can also export a changeset, but I would still recommend using branches.

I've also recorded a video which walks through the process starting with setting up the home server and ends with importing the emailed change package. It's about 12 minutes long most of which is the initial setup and the export/email/import steps take about 5 minutes.

Full Screen Video
video

It would also be possible to automate the import of the package. All you do is setup a service that monitors a POP account or a mail server and then executes the import command on the attached package file.

Tuesday, September 16, 2008

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.

Monday, September 01, 2008

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:

  • Use FILESTREAM to store blobs in SQL Server 2008
  • Storing blobs in database vs filesystem
  • Storing BLOBs in database or filesystem?
  • Should I store images in the database or the filesystem?

    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:
  • 3659 files
  • 468 directories
  • 343 Mb in total

    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

  • I'm using Firebird embedded on windows
  • Don't try with SQL Server... it can't handle blob storage at the same speed... at least not without the latest 2008 improvements
  •