I am a source control nut, I've been speaking about Subversion for years, I co-lead an active open source project which uses git and GtiHub, and I've also dabbled with Bazaar. So far I'm feeling the limits of Subversion, loving the code-hosting features of some of the DVCS tools, and hating git and github in equal measure (don't bother to try to talk me out of this, I'm well aware the problems are mostly on my side). I don't know anyone else using Bazaar in the PHP community but I do know quite a few people raving about Mercurial, or Hg. This post is a quick introduction to the commands I have been using since I started trying out Hg and BitBucket for myself.
In October I will be speaking at the PHP London user group on Thursday 7th at the Theodore Bullfrog pub in London. I'm giving a new talk called "The Source Control Landscape", looking at the products currently available in the source control arena, how the distributed systems have changed the landscape, and how we can choose between them all today. I'm really looking forward to the event, it's always a good crowd and I love to meet new people as well as meet up with existing friends - see you there :)
Recently I've been using bzr-svn when I'm working with subversion repositories; its a bridge between a local bzr repository and a remote subversion one. I travel fairly frequently and the pain of being disconnected from the server, unable to diff or log, and then either unpicking everything I've done or sending a monster commit with the message "Things Lorna did in the last 2 days" is just tedious and annoying. Possibly more tedious and annoying for the rest of the team than me even, so a better solution is more than welcome!
Some time ago I blogged about starting to use bzr-svn but its taken me a while to get past those first steps. Having the repo locally is so fast to use, and the speedy diff and log functionality had me completely sold straight away. I've been mildly annoyed by bzr squashing my commits though, meaning that I'm still doing a single monster commit to subversion when I come back online after being gone for a few days.
Today, with some help from the very lovely people in the #bzr channel on freenode, I found out how to preserve my commit history when sending the changes back to subversion from bzr-svn. The bzr-svn user guide recommends a particular set of commands, but this includes merging your changes into the mirror of SVN. Even in a standard bzr branch, this would show in the logs as a single, combined commit.
Push, Don't Merge
The key to retaining the commit history is to push changes from the branch, rather than merging into the trunk mirror. To make this clearer, I've shown an example. The SVN is checked out into lorna-trunk and I'm making changes in the lorna-branch directory, including adding the db directory and the hello.php file.
$ bzr commit -m "initialising database files and hello.php" Committing to: /home/lorna/data/personal/publish/tek10/svn_vs_distributed/bzr-svn-example/lorna-repo/lorna-branch/ added db added hello.php added db/setup.sql Committed revision 2. $ bzr push ../lorna-trunk/ All changes applied successfully. Pushed up to revision 2.
No matter how many times you commit, when you push, all your changes will be sent to subversion as individual commits in the same way. This will really help me next time I'm offline for a little while!
When There Are Changes In Subversion
Charmingly, while answering my questions to get me this far, the #bzr channel inhabitants then immediately explained to me that to handle changes in subversion, I'd have to rebase my branch before I could push my changes. This is because you can only push to a branch that is in sync with where yours was when you started making changes. If you try to push to subversion when there are changes in it, you will see this error:
bzr: ERROR: These branches have diverged. See "bzr help diverged-branches" for more information.
All I needed to do was to run bzr update in the mirror, and then rebase my branch onto that. At first my system didn't recognise the rebase command, but this was because I needed to install the bzr-rebase package (called bzr-rewrite in newer versions but bzr-rebase in mine, Ubuntu 9.10 Karmic Koala). Rebasing was easy to do and brings the changes from the repo into your working branch. Here are the commands and how the output looked for me (with shortened paths to make this more readable):
[email protected]:~/.../lorna-branch$ cd ../lorna-trunk/ [email protected]:~/.../lorna-trunk$ bzr update +N readme All changes applied successfully. Updated to revision 3. [email protected]:~/.../lorna-trunk$ cd ../lorna-branch/ [email protected]:~/.../lorna-branch$ bzr rebase ../lorna-trunk/ All changes applied successfully. Committing to: /home/lorna/.../lorna-branch/ modified hello.php Committed revision 4. [email protected]:~/.../lorna-branch$ bzr push ../lorna-trunk/ All changes applied successfully. Pushed up to revision 4.
I haven't had a lot of experience with using this in difficult situations with complex branching or conflicts yet, if you have any tips to add though, a comment would be excellent :)
Here is a quick howto on using a config file to associate an SSH connection with a particular identity file. When I ssh directly from the command line, I can specify the port, identity file to use, and a whole raft of other options. However these options aren't available when checking out from subversion using svn+ssh, and I needed to specify a particular private key to use. These instructions are for my kubuntu 9.10 installation but should work on every flavour of *nix as far as I know.
I was trying to check out using something like this:
svn co svn+ssh:[email protected]/desired/path
To do this, I created this file: ~/.ssh/config and in it I put the following:
Now I update my checkout syntax to make use of my alias rather than specifying the host directly, like this:
svn co svn+ssh:[email protected]/desired/path
SSH realises that it should pull the host information from your local config file, and uses your HostName, IdentityFile and any other settings you specify (there are many options, see this reference for more information. For example I often use this for port numbers if I'm tunnelling my SSH between places, the possibilities are endless.
Hope this helps, if you've got anything to add then I'd be delighted to see a comment from you.