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
dstRepos: a full repository spec
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
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.
news ( 119 ) mono ( 30 ) merging ( 23 ) integrations ( 22 ) distributed ( 20 ) best practices ( 18 ) branching ( 14 ) semanticmerge ( 14 ) git ( 12 ) scm ( 11 ) c# ( 9 ) fun ( 9 ) testing ( 9 ) performance ( 7 ) solaris ( 7 ) branch explorer ( 6 ) configuration ( 6 ) visual studio ( 6 ) differences ( 5 ) migration ( 5 ) Agile ( 4 ) Scrum ( 4 ) backend ( 4 ) delphi ( 2 ) unity ( 2 ) eclipse ( 1 )