linuxNUS and the version control workshop

As there was no S.League game yesterday evening, I was free to drop by the iCube auditorium for the linuxNUS technical workshop on version control using Mercurial. It was pretty well attended, and there was plenty of pizza on offer as is the custom. However, there were some areas that the current coreteam identified as possible points of improvement, such as the delivery of the how-to portion, which went a little too fast for the audience to catch up.

I was a bit lazy to get up and help at first, owing in part to my attempt to do other work at the same time and in part to my lack of knowledge in the matter – I have SVN, but not really used it – but when I did, I noticed that several participants couldn’t really understand what was going on because this was, naturally, their first time installing and playing around with the software. Following instructions on blind faith would have worked if everyone was on the same operating system and had the same confidence with the command line that Ray Chuan had.

Now, I love the command line myself, and like Ray Chuan, I can be a little too fond of it for the general public. While I guess I wouldn’t appreciate the blinding speed with which it seemed Ray Chuan was going through the instructions, I could see he was trying his level best to get the points across, and I’m sure he knows by now that there are a few aspects of his delivery that can be improved on.

So what the helpers did was to make sure each instruction was understood, and to perform troubleshooting where it was needed. The diversity of platforms didn’t help, with Windows GUI, MingW, Mac and Linux competing for attention, and neither did the diversity of experience with the respective operating systems. I, for instance, haven’t been using Windows for a long time now, though of course some lectures require certain software that only works well on Windows for some reason, and as such there is an extremely valid practical reason to use such things on Windows. This meant that I had to ask for help myself while helping people who used Windows, though I could chip in a little bit when it came to the Linux end of things.

I guess that roughly mirrors how it is like in a typical support situation with open source software, except we were a little more proactive in constantly checking if people had any problems. Otherwise it’s the same because we helped where we could and turned to others who knew what we didn’t, so that the problem could be solved. Normally, of course, the onus is on the person with the problem to describe the issue in detail so that others who know better can diagnose the problem or suggest solutions. Oh yeah, and we didn’t tell anyone to RTFM. 🙂

The slides will be up soon, though I think maybe I could note the things I remembered from the session here:

  • Username in .hgrc
    • Create the file in the $HOME directory using a favoured editor if it doesn’t already exist.
    • Add the lines below into this file:
      [ui]
      username = This Mercurial User <spaces.dont.matter@developer.com>
    • Save it.
  • hg init <repo name>
    • This creates a repository of the name <repo name>, which is a directory but with added secretsauce to allow tracking.
    • The secretsauce is in the directory .hg, which means you probably don’t want to touch it.
  • Copy or download the necessary code or whatever files into the directory <repo name>
  • hg status
    • Use this to see what’s happening with the files in the repository directory at any moment.
    • Key to the status of the file is the character before the filename:
      ? means the file is not tracked, A means the file is added, M is for modified and C shows the file is clean.
  • hg add <file name>
    • This adds the file to the tracking system. Use hg status again to verify.
  • hg commit
    • What you do when you’re done making changes to your code. This throws the latest version of stuff into your repository.
    • Stuff that’s different in files of the same name will of course overwrite what was there before, though the old is kept.
    • You’ll be prompted for a message. Add a message you want to mark this edition with.
    • If you already know the message, use hg commit -m <message> or hg commit –message <message> to save time.
  • hg clone <repo name> <clone name>
    • This makes branches of existing code by copying the code and the history from <repo name> into <clone name> so work can go on independently, or simultaneously, or both.
  • hg revert
    • Brings the repository back to a previous state. Not too sure how this works, missed the explanation bits.
  • hg diff
    • This didn’t work for me, though it’s supposed to show differences in the Universal diff format. Not sure why.
  • hg merge
    • Combines separate branches into one, and the bits that conflict can be selected at will. Not too sure on this either.
  • hg log
    • Shows a list of commits with the contact information of who committed them.
    • The number of past commits can be controlled with the -l or –limit argument, as in hg log -l 5 for the last 5.

This is what I got, so if I get the chance I’ll top up the difference.

Hope this helps someone somewhere somehow… if not, it would be good notes at least.

This entry was posted in Just Me, Tech. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *