Mercurial vs Git

Most posts about distributed version control are written by people who are biased to one particular solution. This is usually because that person has a wealth of experience in one system, and not so much experience in the other.
This post will be no different.

Prerequisite

I'm biased to windows. I know this. Mac and Linux users live in a different world to your average .NET developer, and that's always going to influence how I view these products.

Git's GUI Offering

Git offers Git for Windows. It's sub-standard, you can't see a branch map, it crashes and falls out of sync with the command window, and you can't do a fraction of the things in the GUI that you can do on the command line. This includes merging and removing branches.
I understand that the makers of Git are trying to make their product more palatable to Windows users, but in my humble opinion, if they are going to try and offer a GUI to do this, bin Git for Windows, and make better use of third-party components.

Third-party components

Mercurial actively offers TortoiseHG as a compliment, and its benefits are huge. You're able to create, merge and close branches, push, pull and contort Mercurial to your whim with a few clicks of a mouse. For Git, TortoiseGit is on its way, but it needs to be pushed harder as a package, because public ignorance of it as a product choice is high. Proof of this is the fact that there are still people trying to find ways to allow TortoiseHG to work with Git repositories!

Conclusion

I know that lovers of the command line will always prefer a black screen with coloured writing to provide them with text-based representations of their source control. I'm also very well aware of how powerful both products are in their purest CLI-based form. However, in three weeks of using a combination of the Git for Windows GUI and the command line interface (not to mention a LOT of Googling and documentation-reading!), I still couldn't do a fraction of what I learnt to do using TortoiseHG and Mercurial in the space of a week.
Productivity must not be made to suffer to be one of the cool kids.

Opening a new window with a linkbutton control

I couldn't do it, and it turns out that lots of other people can't do it either.

They tried to set the navigateurl attribute to the url they want, and then when they tried to open the link in a new window, they got a load of javascript in the address bar and no link.

There is a legitimate way around this, but it involves extending the linkbutton, which I didn't have time to do.

If you do want to do it though, you should try the 4guysfromrolla article, because it does give quite a nice explanation.

If you want a quick workaround, I suggest that you do the following:

Swap your linkbutton link with a regular anchor tag.

<a href="#" id="linkTag" runat="server">This is an example link</a>

That'll be enough for your aspx page. The runat tag and id tags are new and allow you to get to the control from the code-behind.

If you're modifiying the control within a datalist or a datarepeater, you'll need to use findcontrol to get hold of it. If you do, you'll need this code:

Dim link as new htmlAnchor

link = e.item.findControl("linkTag")

The above creates a new anchor tag control and finds the one on your page.

However, if you're just accessing it within a regular function that isn't binding data, you can assign the bits you need like this:

linkTag.HRef = "http://karlitr0s.blogspot.com"
linkTag.innerText = "Karl's Blog"
linkTag.title = "Karl's Blog"
linkTag.target = "_blank"

The innertext tag is for labelling your link.
The href tag points to where you need to go.
The target tag is the html equivalent, and opens up the new window for you.

Doing it this way instead of using Javascript:window.open('') in the href tag means that you don't get your original page from displaying [object] or whatever your browser does when it doesn't understand where it's going within .NET.

Definately the quickest and easiest way around it, but if you have to use external links a lot in your application or you have to utilise the postback as well, you're probably better off extending the linkbutton.