Bitbucket and Mercurial

It has been recently announced that Bitbucket will be leaving Mercurial support in 2020 [1], defaulting to Git from then on.

A lot of things come to mind when reading the announcement, mostly because Mercurial has been my first distributed revision control system or at least the first one I understood. It's fairly simple to use, concise and with a simple interface, but sadly has fallen in popularity.

Git has won in other fields where popularity is more important that correctness and simplicity. If I would go back in time and choose between Git and Mercurial, I would still choose Mercurial, it's still a great tool.


[1] https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

An advice towards Mercurial

This is not a rant, really, just a some few things I would like to write down.

History

When I started into development I've got the great suggestion to use revision control systems, the first one that I ever used was CVS, it really worked well for my own purposes, just had some issues with the sharing-between multiple machines.

Then Subversion was the hot-thing and it was a bit better that Subversion, but still had some of the things that I disliked from CVS.

Then GIT showed up, the projects I was working on required CVS, so I got an early non-official version of git-svn and started working with it, it was great, so many of my problems went away, but it was still under a SVN server.

After that , Github, Bitbucket, Kiln, and the tipping point, everybody switched to the reasonable choice, distributed revision control systems, and I think the best summary for why this approach is better than others, is described by Joel.

My point

My point is not to tell which tool is technically better, my point is more subjective, I think that Git is still technically the most advanced approach you can have for revision control systems, but it might not be the most simple one to use.

I have used a lot of tools, and among all of them the one that still holds my thumbs up is Mercurial, here some few reasons:

• Simple and concise user interface (commands)
• Better merging strategies
• No automatic commits on merge
• Good performance
• Simple to explain
• Gentle learning curve
• Consistent tooling 

 Not too many reasons, rights? that's why I like it, because it just works, no porcelain/plumbing, just the tool. The other tool that goes beyond this is Fossil SCM, but it still needs adoption.

So in the end, my suggestion, if you are using revision control systems and you are unhappy with Git, or you don't know any other tool, give Mercurial a try.

Development tips

I've worked in some projects so far and I learned some things that can save you a lot of time even if they sound very expensive. These tips are meant for small/medium size projects, perhaps you can apply them to big projects, but I'm not sure.

1. Revision control system from the beginning.
2. Define your goals and milestones, even without dates.
3. Define what you are going to build, with use cases or user stories, or just use whatever you feel comfortable with.
4. Define an architecture, don't go on without this. The architecture must define the form of the system, not the details.
5. Define the contexts you are going to be working on, this means that you have to separate your project into smaller micro-projects (if it applies).
6. Define your frameworks/libraries stack.
7. Define your project(s) structure, this involves folders and files.
8. Define your automated build scripts, something like Gradle would do it.
9. Think in the tests before the implementation, if it's testable, it's implementable.
10. Use continuous integration from the beginning.
11. Keep you source files small and readable.
12. Periodically check your system and update the architecture if some changes have been made.

I omitted several things, but I consider these the most important from a developer's perspective.

I didn't have this information at the beginning because I was too lazy to read about it, and had to learn it the hard way, by suffering the consequences...

Fossil SCM

A few months ago I listened to FLOSS Weekly's episode about SQLite, and I wondered how this wonderful project was being managed.

After checking for a while, I found that D. Richard Hipp has developed his own distributed SCM based on the very reliable SQLite.

In a comparison with Git and Hg (which I have used), it is more than a SCM, it is a whole project-development space. Some of its features include:

• Bug Tracking And Wiki, really cool.
• Web Interface, incredibly simple.
• Autosync, still wondering what its benefits are.
• Self-Contained, yep, everything in one binary file.
• Simple Networking.

As a developer of some internal projects, it's really hard to keep track of my bugs an issues, and the environment required for it costs too much. But this amazing project does it for me!

Its use is very similar to any distributed SCM and the installation/configuration is barely present. I totally encourage you to try it.

Configure DiffMerge on MacOSX

Based on this article, I modified it a little bit in order to make it work on Mac:

[diff]   tool=diffmerge                                                                                                                   
[difftool "diffmerge"]                                                                                                                      
  cmd = exec /Applications/DiffMerge.app/Contents/MacOS/DiffMerge \"$LOCAL\" \"$REMOTE\"                                                                                                                                   
[merge]                                                                                                                                     
  tool = diffmerge                                                                                                                    
[mergetool "diffmerge"]                                                                                                                            
  cmd = exec /Applications/DiffMerge.app/Contents/MacOS/DiffMerge --merge --result=\"$MERGED\"\n\"$LOCAL\" \"$BASE\" \"$REMOTE\"                                                                                           
  trustexitcode = false     

gitconfig4j v0.0.1

Another weekend project has been released. As a short overview, one of the things I really love about GIT it's the .gitconfig layout:



I love the simplicity and the clearness of those configuration files, and I wanted something similar for some of my Java projects, but I couldn't find an implementation of it.

So, I decided to create a very small library for supporting git-config file layout for Java. After a couple days of work, I have something I'm not ashamed of.

But well, here you go: gitconfig4j project page

Google tech talk - Linus Torvalds on GIT

Great talk about distributed concurrent version control systems and GIT.

Git svn dcommit, interruption recovery

As usual, I was doing all my work in my local copy(Git) of a SVN repository, when everything was stable and pretty, I started pushing everything to the central server. But in the middle of the operation the network was shutdown, some of my commits couldn't be pushed and my working tree was a mess!!.

"Ok" - I said - "I just have to point to HEAD again... which was the commit number?". I couldn't remember the commit number(is not so easy to do, admit it) but that's not necessary, right?, just do a 'git log --all' and you will see your commits. But NOOOOOOOOO, all commits were up to the last SVN dcommit entry!!!.
e.g.
                                                       * -> 'super commit'
                                                        |
                                                       * -> 'some other commit'
                                                        |
                                                      [*]-> 'where SVN commit crashed'
                                                        |

"Oh shit, oh dear Lord!!, don't worry, Git tracks content, can't lose my commits" - I said. But nevertheless all options I've tried, my commits seem to be lost.

After a few minutes reading Git's manual, I found this:

$> git rev-list --all --pretty=oneline

And.. YES!! all my commits are there, so, to make the long story short:

$> git checkout awfulCommitNumber
$> git svn rebase
$> git svn dcommit

External merge-diff - Git on windows

To configure and use Git in a Linux environment is quite easy, but if you are working in a Windows system, things get a little bit complicated.

I use MsysGit which is a great port to win32, and as a merge/diff tool I use WinMerge (I can't stand KDiff); to work with WinMerge as 'difftool' and 'mergetool' you could do this:

- First, create a wrapper script for our 'difftool', save this file as 'diff-tool.sh' in your $HOME folder:

#!/bin/sh
# Change "E:/bin/WinMerge/WinMergeU.exe" with your winmerge path
"E:/bin/WinMerge/WinMergeU.exe" -e -ub "$1" "$2" | cat

- Now, edit your $HOME/.gitconfig file, you can take as example my current configuration:

[core] 
autocrlf = false 

[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

[user]
name = Timoteo Ponce
email = timo.slack@gmail.com

[merge]
tool = winmerge

[mergetool "winmerge"]
cmd = "E:/bin/WinMerge/WinMergeU.exe" "$MERGED"
keepBackup = false

[diff]
tool = winmerge

[difftool "winmerge"]
cmd = $HOME/diffmerge-tool.sh "$LOCAL" "$REMOTE"

GIT - Working with a SVN repository

Git a SCM created by Linus Torvalds and currently mantained by Junio Hamano, is a distributed revision control system very simple and extremely powerful.

For those people who want to test this system (me included), and comes from a SVN environment, there are some utilities (included with GIT) to interact with SVN repositories.

In my case, I have a copy of a project fetched from the SVN repository, and for local development I use a branch called 'development'. When the development branch is stable, I merge this branch with the branch 'master', and then commit the changes to the SVN repository.

- Create and fetch from SVN repository

git svn init https://localhost/dev/svn/tiergen
git svn fetch -r HEAD

- Create a 'development' branch and start working with it.

git branch development
git checkout development

- After all changes are made in the development branch, let's merge thi with 'master'.

git checkout master
git merge development

- Finally, commit everything to the SVN repository.

git svn rebase # I always do this
git dcommit