plasticrain.com

Over the last few months there has been a lot of talk on the internet about Git – a distributed version control system which seems to be becoming ever more popular within the Rails community. Because of this, I thought I’d follow (sheep like?) the trend and look at moving some of my projects into git repositories. I have started doing this and am now a proud, fully-paid-up, member of github (a nice little git repo hosting service). I do plan to setup my own remote git “store” in the future, but for now, until I have the time to transfer all our subversion content to git – github will do nicely for my current projects.

I could go on about how git is different to SVN and so on, but this topic has been covered to death on the internet so I won’t, but, what I do want to let you see is a quick ruby script I knocked together to simulate the behaviour of svn export http://svn.domain.com/myrepo in git. This takes the form of git-export my_repo git://mydomain.com/repo.git my_branch

You can check it out in my new github account at http://github.com/adamcooke/git-exporter/tree/master/exporter.rb – I have copied it to /usr/local/git/bin/git-export so I can simply run git-export from anywhere on my system.

If your reading this and have any suggestions to improve it, please don’t hesitate to fork the repo and send it over :)

---

Since moving from my Windows PC to my Mac last year, I’ve always have the problem of managing anything with Subversion. In Windows, I had the luxury of the fantastic TortoiseSVN which handled every SVN need I had however on the Mac there is no such software. OK, RapidSVN and svnX try to be good clients, but they simply don’t live up to the high standards set by the TortoiseSVN guys.

So, I had to decide – do I really want to boot up a Parallels install each time I want to commit or update my code? Of course I don’t, so I started playing with the plain old SVN command line. Although, I’ve always used it for quick checkouts, exports, commits and updates I’d never used it for managing a large project where files get added, deleted & moved around on a regular basis so it was time to use it mainstream!

I thought I’d post up a very quick entry about what things I use and how it’s so easy once you get the hang of it.

The two most useful commands during your project’s life cycle will be svn up and svn ci which will update and commit your code respectively.

Update your code before committing

I strongly advise always running an update before a commit – this will ensure that code you commit is at the latest version stored in your repository. It will update your local code to match that in your repo and merge (as best it can) your changes with those which have been committed since your last update.

When you run svn up (from within your working copy), you will be presented with a complete list of all the files which have been updated and each file will be prefixed with a letter – A (added), M (modified), D (deleted) or C (conflicted) are the most common.

Once complete, you should check this list for any files which have conflicted – this means SVN couldn’t work out how to automatically merge the changes it downloaded with those on your local machine and you need to merge them yourself. If you browse to the folder where the file with the conflict exists, you will see 3 extra files – filename.r24, filename.r26 and filename.mine – these files represent the version which matches your working copy revision, the latest in the repository and the copy you have. It is now completely upto you to make sure your local copy, includes all the changes which others may have made using these newly created files as a point of reference.

When you’re happy with your merge, simply type svn resolved path/to/filename to remove the extra files thus marking the file as resolved.

(Rails App Tip: if your developing a Rails application, I advise you to now also run an rake db:migrate to update your database schema.)

Committing your code

Now you’re all up-to-date you can send all your updates to the server. But… wait… you need to check something first!

To check what changes your about to commit simply run svn status (inside your working copy). This will return a list of files similar to that provided by the update command and, as before, each of these will also be prefixed with a letter – A (newly added), M (modified), D (deleted) and ? (not added yet, but in the working copy). As above, you don’t need to worry about A, D and M – SVN knows what it’s going to do with these however, you do need to keep an eye on ?.

The question mark (?) means that you have put a new file in your working copy but it hasn’t been properly added to SVN. To add these files you need to run svn add path/to/new_filename – this will add it and any new output from the status command will show an A rather than a ?.

If you have lots of these files, you can use the useful command below to simply add every file marked with a ? – this is a real time saver if you’ve just added a folder of images or copied in files from another folder.

svn add `svn status | grep "\?" | awk '{ print $2; }'`

Once, you’re happy with the output from svn status, you can proceed to actually commit the changes by running svn ci. When you run this command, your default text editor will open and ask you to enter a commit message – this should outline all the changes you made in this revision – it’s useful to make this as detailed as possible but don’t spend too much time on it.

In summary

This post only covers the very basics of Subversion – there is so much more – svn revert, svn diff and lots of other useful commands which you’ll need to learn if you want to switch all your SVN usage to the command line.

If your sitting there angry with your SVN client app – don’t be scared to explore the wonderful world of the command line. It’s nowhere near as scary as it’s made out to be.

But… please, please, please take a full backup before exploring any new things!

Other resources

The SVN Book is free to download – have a look.

Why not take a look at this basic work cycle for a little more info about the commands available to you.

If you have any questions, please don’t hesitate to post a comment.

---

ActiveReload has recently launched their latest app, Warehouse. It is a web-based subversion browser and its very cool. I’ve spent quite a while today playing with it and exhancing various features such as:

• an option turn a user into a client – the idea behind this is to provide the client with access to a folder within a repo however hiding things which arn’t relevent to them (such as bookmarks and any information about changes in other folders.
• a few atech media logos and information paragraphs
• drop down navigation menu between repos – diff for this here
• various interface changes (colour of top bar is now blue) and title is bigger (see screenshot below)
• removed the default footer as it took up space and wasn’t really needed.
• auto login functionality – diff for this here
• redirect to requested page rather than root – diff for this here

---

Last week, we launched our second web application, desklamp. desklamp is a complete management information system for service-based organisations and features jobs, quotes, invoicing and client management.

Development started in February 2007 and took about 3 months to plan, design, build & test.

Check it out over at http://www.getdesklamp.com – you can sign up for a free 30 day trial or just use our free package.

---