Posts Tagged ‘Version Control’

Password-less Repository Authentication for Mercurial

June 3, 2011

I setup a free account a short while ago at bitbucket with the intention of creating a version control repository for Hg.
So far this has worked out well.

Although every time I communicated with the back end repo I’d have to enter my credentials.
I realized if I added my user name to the URL, I’d only receive a password prompt.

https://MyUserName@bitbucket.org/MyUserName/MyRepoName

If I also added my password in the URL I wouldn’t be prompted for anything.

https://MyUserName:MyPassword@bitbucket.org/MyUserName/MyRepoName

Obviously I didn’t want to be entering this each time I communicated with my back end repo,
also especially with my password in plain text on the screen.
So I did a little research.

TortoiseHg comes bundled with the keyring extension.
So if your using TortoiseHg you don’t even have to install it.
Just add the following to your mercurial.ini file in your user directory.

[extensions]
mercurial_keyring=

You’ll also have to edit your repository specific hgrc file.
If this file doesn’t already exist, create it.

[paths]
bitbucket = https://LethalDuck@bitbucket.org/LethalDuck/code-scripts
default = https://LethalDuck@bitbucket.org/LethalDuck/code-scripts

You could put your password in the above URL too, but that kind of defeats the purpose of using the keyring.
So you associate your username with the URL you are wanting to communicate with.
Now you can add as many URL’s as you like.
As you can see I’ve just added the same one twice, as an experiment to see how it’s handled.
In Repository Explorer, it’ll look like this…

Now when you select either of the URL’s to push to or pull from,
the keyring will prompt for your password once and store it encrypted.

After that, the stored encrypted password is used
and no more prompt.

Resources:
http://stackoverflow.com/questions/1997601/store-password-in-tortoisehg

Tags:
Posted in Version Control | 1 Comment »

VisualHG works nicely in VS 2010 rtm

November 20, 2010

 

For the uninitiated…
VisualHG is a Mercurial source control plugin for MS Visual Studio

 

 

 

 

I had a bit of a problem with VisualHG a couple of weeks ago.
The overlay icons work in Visual Studio, but the context menu had no VisualHG icons and the VisualHG toolbar was inactive (had all the buttons greyed out).

Tried uninstalling / reinstalling visualhg.
Version: Visual Studio 2010 Version 10.0.30319.1 RTMRel Premium.
OS used: Windows 7 Enterprise x64.
VisualHG 1.1.0 installed.
Seems to work in VS 2008 though.

Solution

Remove all instances of VisualHG in Programs and Features.
Search the Program Files and Program Files (x86) for instances of visualhg and remove if they exist.
Search the registry for VisualHG related items (entries as well as keys). Delete them all.
Reinstall the latest version of VisualHG (currently 1.1.0).

Posts and links that provided resolution:
http://visualhg.codeplex.com/Thread/View.aspx?ThreadId=209792
http://visualhg.codeplex.com/workitem/36

Tags:,
Posted in Microsoft, Version Control | 3 Comments »

Distributed Version Control the solution?

October 3, 2010

Due to the fact that I am starting to need a Version Control System at home for my own work and the company I currently work for during the day could potentially benefit from a real Version Control System.

I’ve set out to do an R&D spike on what is available and would best suite the above mentioned needs.
I’ve looked at a large range of products available.

At this stage, due to my research and in talking to some highly regarded technical friends and other people about their experiences with different systems, I’ve narrowed them down to the following.

Subversion, Git and Mercurial (or hg)
Subversion is server based.
Git and hg are distributed (Distributed Version Control System (DVCS)).

–

The two types of VCS and some of their attributes.

Centralised (or traditional)

  • Is better than no version control.
  • Serves as a single backup.
  • Server maintenance can be time consuming and costly.
  • You should be able to be confident that the server has your latest changeset.

Distributed

  • Maintenance needs are significantly reduced, due to a number of reasons. One of which is… No central server is required.
  • Each peer’s working copy of the codebase is a complete clone.
  • There is no need to be connected to a central network. Which means users can work productively, even when network connectivity is unavailable.
  • Uses a peer-to-peer approach rather than a client-server approach that the likes of Subversion use.
  • Removes the need to rely on a single machine as a single point of failure.
    Although it is often a good idea to have a server that is always online and ready to accept changesets.
    As you don’t always know whether another peer has accepted all your changes or is online.
  • Most operations are much faster than the centralised model, as no network is involved.
  • Each copy of the repository effectively acts as a remote backup. Which has multiple benefits.
  • There is no canonical code base, only working copies.
  • Operations such as commits, viewing history and rolling back are fast, because there is no need to communicate with a central server.
  • A web of trust is used to merge code from disparate repositories.
  • Branching and Merging made easier.
  • No forced structure: a central server can be implemented or peers can control the codebase.
  • Although I don’t see huge benefits for a central server in my target scenario.
  • Buddy builds. A team member can pass a change set to another member to try before committing to a central location.
    This would stop broken CI builds.
  • There is a huge amount of flexibility with your layout.
  • With a well planned layout a Distributed Version Control System can do anything a Centralised system can do, with the additional benefit of easy merges.

–

In weighing up the pros and cons of distributed versus the centralised model.

I think for my target requirements,
a distributed system has more to offer in the way of time savings and hardware savings.
This page has a good explanation of the differences between Centralised and Distributed.
Here is a detailed list of comparisons of some of the more common systems.

Mercurial is ticking quite a few boxes for me.
Mercurial has a VisualStudio plug-in.
There is a GUI available for windows platforms and others that integrates Mercurial directly into your explorer.
It’s free, open, and being actively maintained.
Projects using Mercurial.

Mercurial is written in Python, which is another plus for me.
Binaries are freely available for Windows, GNU/Linux, Mac OS X, OpenSolaris.
The source is also available, so you can build it for most platforms.

Plenty of documentation here, plus the book.

Installation and Configuration. Covering Windows, Debian and more.
TortoiseHg has binaries for windows and debian, but only for Squeeze onwards by the look of it.
If your running Lenny, you can just use hg. apt-get install mercurial.
When I downloaded and installed the 64 bit version of TortoiseHg (v1.1.3 hg v1.6.3), it came with 4 comprehensive documents.

  1. Mercurial: The Definitive Guide 2010-02-21 as pdf
  2. TortoiseHg v1.1.3 Documentation in both pdf and chm
  3. Mercurial Command Reference

Very nice!
Turn off the indexing service on the working copies and repositories, and exclude them from virus scans.
Can also get TortoiseHg here (For Debian, TortoiseHq isn’t available for Lenny).
Click the Tutorial link for the Quick start guide to TortoiseHg.

Once installed, start working through the following links.
http://tortoisehg.bitbucket.org/manual/1.1/quick.html
http://mercurial.aragost.com/kick-start/basic.html

Comments or thoughts?

Tags:, , , ,
Posted in FreeBSD, GNU/Linux, Microsoft, Networking, Version Control | 3 Comments »