The Dopefly Tech Blog

« The Dopefly Tech Blog Main page

Version Control Software Isn't Just For Code

posted under category: IDEs and tools on March 17, 2016 by Nathan

Many years ago I read an article where someone put their linux-os home directory in source control - probably CVS at the time, this was a while back. He’d had it running that way for a long time, too, and could roll-back his desktop to last week, checkout the latest version on any new PC, throw away destructive changes, and save & commit beneficial changes. It got me thinking. Version control software isn’t just for code, it’s for any file.

Years ago, when playing Minecraft server admin for my kids, I came up with the idea to put their Minecraft world into Git. We could check in changes nightly, which would allow us to blow everything up and just roll back, or invite a destructive friend over and then undo everything he did. It also gave us the ability to clone the server into a local world when the server was too slow, play locally, then push progress back up to the shared server. And then there’s branching - one child could go out and do stuff in another part of the infinitely generated world, then merge changes back on to the server if it worked out, or drop the branch if it didn’t. It’s brilliant. It ended up a little more work than anyone wanted to do, but the idea was there.

Recently, when researching backup software, I found two real categories of solutions for backups:

  • Your backup is just a copy of your files on another server or drive, with no historical data integrity
  • Your backup software in a database somewhere, but you have to use specialized software to retrieve your files

After searching for a while, I found bup. It’s actually based on Git, which gives you the best of both worlds for backup software - a live, local copy of files that you can browse like any file, plus versioned incremental backups that you need a special client to retrieve. You can host it on a file share, and effectively, git-clone (technically bup-clone) to add another backup server.

I’ve no doubt that there are a million other potential uses, too. Version control software is not just for programmers and code!


I am switching to Git

posted under category: IDEs and tools on July 27, 2011 by Nathan

I've been a pretty big fan of revision control software since I started hearing about it. It's crazy that I was a developer for so many years before I heard about it at all. I guess that's what I get for keeping my nose to the ground (note to self: write about being a new developer and getting connected).

I thought I had skipped the entire CVS generation until I joined a very large, almost 100 year old company. Boeing loves CVS, I guess just because it's reliable and was around when they set up their servers. My CVS server is doing fine, but it's slated for a migration to a new data center, possibly facing an end-of-life soon; the guy who maintained it left the company over a year ago. Naturally, I looked into Subversion. There is an enterprise hosting group that hosts SVN over SSH, which means SSH software, managing keystores, telnetting, all kinds of things that I am not a fan of. I had it working, just barely, only through Tortoise and not Eclipse, but it was hard and I would have to help all my teammates get it to work, too. They're smart, but this setup is harder than I want to work. I would have migrated to SVN, but they made it way, way too hard.

The great news is that they do make Git available to me (if I know where to look [Boeing has a strict software installation policy {I can only install the software they give me <recursive parentheses are fun «sometimes»>}]).

I had big initial troubles with understanding the concepts of Git. Everyone who switches has the same trouble. Expect it and don't let it get you down. Git uses a lot of the same words with different meanings, and the need to branch and manage branches is much more prevalent. I found EGit (the Git plugin for Eclipse) completely confusing and stupid. The command line was out, come on, this is 2011. Even TortoiseGit was acting broken. I needed help, and lots of it.

Thankfully, I got to attend two different hour-long Git sessions with Tim Cunningham, who pointed out some other resources. I watched a few other videos, the best was probably Jenny Donnelly's Introduction to Git from Yahoo. Then I read a lot, practiced some, and finally, here I am - switching!

I came to terms with EGit and TortoiseGit - they both make sense now and they work great. I use the Git Bash shell now and I don't even feel weird about it. I keep a cheatsheet on my wall and refer to it regularly.

It's at this point that I can look for the real benefits, to see if this little project pays off.

My Git architecture is very simple and based on what Tim showed off. It's simple file shares across the network. At first it sounded awful, but in reality this works like a charm. The shares are backed up. I control file access. I just have to enforce a couple strict pushing practices and everything is gravy.

I think what I most like about this setup with Git is that it inverses the control (IoC! [kind of]) of my source control software. Where before I needed a server, IT hardware support and had one repository, now I make and control the repository when and where I want it. Where before committing to a subversion repo on a flash drive seemed like a half-broken hack and it would never sync to a remote server, now it's a way to win easily. It feels liberating. It's really cool. This developer's tool doesn't need a server anymore. It just needs a capable developer. It's developer's software for developers, and I love it.

As I've progressed with Git, I have branched and merged and pushed and rebased and stashed pulled and diffed. Some of it has been a big challenge, like putting current work aside to get out a quick fix, I had to learn to stash, then make remote branches, and so on. It's tough, but thanks to google's index of stackoverflow, I'm making great progress!

In summary, Git is good, you should learn about it, give it a try and have patience.


Start Eclipse faster with -initialize

posted under category: IDEs and tools on April 10, 2009 by Nathan

There was some good discussion today on the CFEclipse Users email list about getting Eclipse to start up faster, and I offered this suggestion:

Run this command when you log in to your workstation:

eclipse -initialize

According to the most complete reference I could find on Eclipse's command-line arguments, the initialize command:

Initializes the configuration being run. All runtime related data structures and caches are refreshed. Handy with shared installs: running Eclipse once with this option from an account with write privileges will improve startup performance.

The emphasis was mine, and for good reason. It really works!

In a very cheap experiment, using the windows clock as my stopwatch, I closed my open Eclipse (version 3.5, galileo M6), waited about a minute, then started it again. My PC took a full 60 seconds to load my workspace again.

I closed it, and called eclipse with -initialize through a windows shortcut. The initialize command doesn't really seem to do anything, and it took about 5 seconds to complete. After that, I waited 30 seconds and started Eclipse again, this time it took 16 seconds! Closed it, started it, 16 seconds again!

I guess I would have to reboot to get a cold start time, which is more than I'm prepared to do for today's little blog post. I really don't know what -initialize does under the hood, but wow, what a difference it can make.

Nathan is a software developer at The Boeing Company in Charleston, SC. He is essentially a big programming nerd. Really, you could say that makes him a nerd among nerds. Aside from making software for the web, he plays with tech toys and likes to think about programming's big picture while speaking at conferences and generally impressing people with massive nerdiness and straight-faced sarcastic humor. Nathan got his programming start writing batch files in DOS. It should go without saying, but these thought and opinions have nothing to do with Boeing in any way.
This blog is also available as an RSS 2.0 feed. Click your heels together and click here to contact Nathan.