- http://cssglue.com/cubic & http://cssglue.com/matrix – Visualise and manipulate CSS transition timing (easing) functions and matrix transforms
- http://easings.net/ – easing functions cheat sheet
- http://cubic-bezier.com – Bezier curve tool
- http://www.semanticmerge.com/ – Semantic merge tool
- http://www.layoutit.com/ – Twitter Bootstrap interface builder
- http://www.unheap.com/ – nice repository of jQuery plugins
Subversion has been the version control system used on all projects I’ve worked on so far apart from one, which used Git. So when I wanted a VCS for a small personal project, I was keen to try Mercurial. Although I realise that with only me working on it, I won’t get the full experience of using Mercurial.
First good thing for my use case is that it doesn’t require me to set up a local server – good.
I can recommend the Hg Init tutorial by Joel Spolsky, which includes a section on “Subversion re-education”. The key things I’ve picked up are:
- “Mercurial separates the act of committing new code from the act of inflicting it on everybody else”
- “because Mercurial thinks in terms of “changesets” instead of “revisions” it can merge code much better than Subversion”
- “that means that you can feel free to branch because the merge isn’t going to be a nightmare”
- unlike in SVN, all commands apply to the entire tree (rather than just the directory in which you invoke the command)
- in a company, you’d therefore want many smaller repositories for each project rather than one big one
- “pulls” pulls the latest changes to a local repository, doesn’t switch our working copy to actually use them
This Stack Exchange Programmers question is also worth a read, as well as Martin Fowler’s article on Version Control Tools. The latter has an interesting idea at the end which is to use multiple VCSs to get around issues caused by corporate standards demanding the use of a “deficient” VCS such as Visual SourceSafe.
Thoughts on good practice when using version control, based on my experience, and not in any particular order.
Commit one “thing” at a time, where “thing” is a feature or a bug fix. Don’t commit a feature at the same time as a bug fix, or multiple bug fixes at once.
Review what you’re actually committing – the files, and their contents. You may have temporary changes to some files, you might have forgotten to deal with a FIXME, you might have used an editor that’s messed up the whitespace/indentation of entire files.
Sometimes you get called upon to fix something while you’re working on a feature, with some half-done changes in your working copy. Create a branch, switch to it, commit your half-done stuff, then switch back to trunk to fix whatever it is. When you’re done fixing, either continue your work on the branch or just merge it in to trunk straight away and carry on.
Commit messages should say what you did, and if relevant, why (e.g. what issue it fixes). Bad examples are “changed js file”, “fix bug”. If you’re working on a feature and make multiple commits, “<name of feature>” is not a good message.
Learn how to resolve conflicts properly, take care when doing it, and test after merging (even if there were no conflicts). If in doubt about a conflict, ask someone. Learn how to resolve tree conflicts properly. Use a clean working copy for merges.
Learn how to revert committed changes (reverse merge), or ressurect files with history (svn copy).
Preserve history on file moves. Use svn move, or your SVN-enabled IDE to move files. These will track the fact that the file was moved, and the history will remain linked in SVN – this is called “addition with history”. If you just use Windows Explorer, your move will become just a delete and a corresponding unrelated add.