One of the things that I do quite frequently is download new packages and bits and pieces of code to play with on my local machine. I frequently start making local edits to perform local configuration changes, or perhaps try out the odd idea. Quite often these packages are downloaded, played with, and then discarded if they don’t meet my needs. But of course some of them end up with a permanent place in my tool chest, or installation.
Exploring with Bread Crumbs
I start getting twitchy if I start making changes to anything without checking them in somewhere as I go. It is all too easy otherwise to lose track of the changes you have made and quickly get yourself into a mess, losing lots of time and effort.
So, like Hansel and Gretel, I prefer to leave a trail of bread crumbs along the way so that I can explore safely (avoiding if possible my breadcrumbs being eaten by the birds!).
I view this as being able to explore while having the safety net of my saved versions stored away. Advantages:
- I know what I have changed at any point (can show what’s changed and do diffs)
- I have a bread crumb trail leading me back home to my initial clean configuration
- I can revert to known working states if the current experiment goes wrong (e.g. accidentally delete chunks of text in the editor, or change several settings at once without appreciating their interactions)
Bread Crumb Trail Tools
My tool of choice for SCM is Perforce which is fast, effective and has lots of client tools. Having used it for many years as a consultant and trainer it is second nature to me and quick and easy to use, and rock solid.
And yet, for this particular type of work, I find it not always ideal. Why?
- I need to setup a client workspace – not difficult, but enough steps to still be annoying and to often result in me not doing it (requires making decisions on naming, default paths in the repository etc – seems like it could be easily automated, but just slightly too variable in requirements to make this easy)
- The changes are “permanent” in my repository – even if the whole experiment turns out to have been a red herring (and yes of course I can obliterate stuff, but that’s another extra step)
Please note that if I really want to keep all my work – for example the package turns out to be of long term use, then I make the small extra effort and import into Perforce (together with third party codeline pattern etc to be able to track future changes as new release are made etc.). At this point, it turns out that saving it “centrally” is very beneficial.
Bread Crumb Tool of Choice
My favourite current tool for this “temporary” bread crumb saving is Mercurial (hg).
The advantages for me:
- It is very quick and easy (but also a full featured system should I ever need it)
- The “repository” is saved in the .hg directory at the root
- If I remove the whole tree then repository goes too
I use the command line client to save an initial snapshot (from the root of the tree where I have extracted the package):
hg init . hg add . hg commit -m "Initial version of XXX as downloaded"
Subsequently I typically use the following subset of commands (from “hg help”):
- add add the specified files on the next commit
- commit commit the specified files or all outstanding changes
- copy mark files as copied for the next commit
- diff diff repository (or selected files)
- help show help for a given topic or a help overview
- log show revision history of entire repository or files
- remove remove the specified files on the next commit
- revert restore individual files or directories to an earlier state
- status show changed files in the working directory
TortoiseHg is also useful.
Conclusion
Perforce remains my tool of choice for most SCM related activity, but Mercurial is a very useful addition to my personal tool chest, and in particular in this type of scenario.
The main thing I would always encourage people: Whatever you do, get into a habit of using a version control tool as often as you can! You will seldom regret it.