Plastic goodness

First, excuse me for the long time without posting here. Life is taking all my time and I'm becoming really busy.

Me and two other friends have got accepted a city generator project proposal, and things are coming along quite nice (a bit time-shifted from the estimated timing, but quite nice after all). Here's a shot of our (to be rejected later) prototype for you all to enjoy :P


What you see there is the parametrisation test for an image-based input, to be used,
for instance, for population density. Nothing really spectacular, but I'm proud of it XD

Now onto the topic. After almost a month of development, I've gathered some knowledge about the usage of PlasticSCM for the software configuration management (guess what SCM means? :P). So without any further talking, I'm presenting my tips:

Workspace-per-task
...and branch-per-task. THE COUPLE -- all caps. I knew Plastic was good managing branches, but this is just a breeze. We gave the branch-per-task pattern a try and I must admit that Plastic is really overwhelming here.

In addition to that, as our codebase is intended to be rather lightweight (that's the purpose of procedurally creating content ;)), we can allow ourselves to have several workspaces/views created at each machine of ours. The deal is that you will have several workspaces placed in directories such as task0002, task0014... (yes, we also have mainline separately ;)). Each of them point to their respective branch, so switching branches is actually a cd ../taskxxxx command ;) I've found this really speed-boosting, so we can avoid the updates that must come along with each branch switching, as well as easing the process of merging.

Alias is not only a TV series
NO, I haven't drunk. Not many people know about the Linux shell command alias. This command lets you bind a non-physical shell script with a shell command. You can read this as having virtual scripts, merged with the environment variables concept. The best deal is that this can be used to save efforts and "record" common tasks such as checking in all the checked out items. Indeed, I've created two aliases for this purpose:

alias unco-all='cm fco --format={4}|cm unco -' alias ci-all='cm fco --format={4}|cm ci -'

The best is that they still accept options for unco and ci, so it's still possible to add comments to the changesets (amongst others!)

Pseudo-integration with Nautilus
Thought about this trick this morning, and after learning how Nautilus scripts work, I've finally got a system to do check outs, check ins, and undoing the check outs from the file browser.

Entering ~/.gnome2/nautilus-scripts and placing there scripts (any runnable script indeed, be it standard Linux shell scripts, perl, Python or whatever) will add new options to the file browser.

My approach has been to write three scripts, Checkin, Checkout and Undo\ checkout to a subfolder named PlasticSCM. Nautilus defines a number of environment variables when running these scripts, so using NAUTILUS_SCRIPT_CURRENT_PATH and NAUTILUS_SCRIPT_SELECTED_FILE_PATHS lets you perform those operations on the selected files and folders.

And if you add some error checking and notify-send... Sweeeet.... :D