Al Hoang

In Mercurial I noticed one new feature in the commit command that lets you specify a commit date.

$  hg commit --help
 -d --date       record datecode as commit date

Too bad the help is too sparse to explain the commit date format. Luckily I found a good explanation at the URL below.

Thanks!
http://blog.littleimpact.de/index.php/2009/03/03/usage-of-hg-commit-date-mercurial/

Luke describes a nice methodology for using Mercurial as a way to track patches from a subversion checkout. This type of workflow stuff is very cool imo because it has the following:

1. Shows a concrete example of how to use a not so trivia tool
2. Works within constraints (in this example, playing with a subversion checkout)
3. Fills a need (Managing non-trivial changes to a centralized SCM model without sending tons of commits)

Read More

iBanjo talks about hgsubversion which seems to be a good mercurial-subversion bridge at last.

I’m surprised it took this long to show up but I guess the Mercurial community had not prioritized ‘Build a better git-svn’ as something someone should roll out… until now.

Installation still looks a little painful (and requires lots subversion 1.5 libraries) but I am optimistic this will start gaining traction for those that need to integrate with a subversion world.

while lukingz 4 moar informashun on distributd scms (again) i findz post by dave dribin bout y he chose mercurial 4 hims needz. but even moar awsum iz hims darin furball.

far 2 awsum. let teh semantic web has cheezburgers, man.

• Daring Furball
• Lolspeak translator

Keith Packard of X11 fame wrote a blog post on revision control repository formats. In it he describes why he chose git as the new system that will manage the source code for Xorg and he had some choice comments on Mercurial repository format

Mercurial uses a truncated forward delta scheme where file revisions are appended to the repository file, as a string of deltas with occasional complete copies of the file (to provide a time bound on operations). This suffers from two possible problems—the first is fairly obvious where corrupted writes of new revisions can affect old revisions of the file. The second is more subtle — system failure during commit will leave the file contents half written. Mercurial has recovery techniques to detect this, but they involve truncating existing files

However, some people who use Mercurial have answered back to those criticisms.
RVBurke writes:

Mercurial uses a compact representation of data with separate revlog files for each tracked file, manifest and changelog, which are all append-only. Due to the append-only nature of those writes, the changes in each new revision don’t affect previous revisions. You are that way as safe as you can be in any other system with respect to writes and the space usage is very good.

To achieve similar space efficiency git needs to pack the repository data. This is done rewriting the repo, and the operation has to be done from time to time (repack).

IF the atomic append-only writes to the manifest and revlog files in Mercurial can be considered dangerous, then repacking is even more so, as it forces a rewrite of all the repo data, multiplying the chance of a failure.

So, if any corruption can happen on a faulty write it will hit git (unpacked) or Mercurial in the same way, but anytime you pack your repo in git you’re risking your data and the write fails you can corrupt its repository.

and Matt Mackal in an email to the Mercurial mailing list has the following reply:

Mercurial files are append-only. New revisions (corrupted or not), do
not affect old revisions. If a hardware or operating system bug causes
a write to scribble over the wrong part of a file, all bets are off of
course. But such bugs could just as easily scribble over any other
part of the disk, so I think this is no more of an issue than it is
for any other possible system.

Personally, I’m a bit confused. I’m not an expert on repository formats so I don’t fully understand whether the criticism or the defense is stronger. However, I have chosen to use Mercurial in most of my own personal projects because it has one feature for sure that git does not. Windows compatibility. While many will denigrate native Windows compatibility. It’s also good to remember that a huge portion of machines on this planet still run Windows. The fact that there’s little information on running git on windows besides ‘Install cygwin’ makes it hard to evaluate whether git is ‘good enough’ on Windows or not.

I’ve been playing with Mercurial a bit recently as I wanted to get the hang of a Distributed Source Code Management (DSCM) tool better. I’ll save my reasoning for choosing Mercurial for another time. Let’s get to the troubleshooting part.

Mercurial provides a Windows version and some instructions on getting it running for basic cases however what I found I needed were:

• Repository syncing via SSH
• Getting vim to fire up as my default editor when I made commits

After a little bit of head-scratching I finally figured out these are the steps you need to get those working:

1. Install Mercurial Win32
2. Install cygwin and make sure to also choose openssh from the packages you install with cygwin. If you like some other ssh client from the command line you can use that but I couldn’t get plink to work properly but cygwin worked fine for me
3. Install the Windows version of vim and make sure that vim is added to your PATH (I believe you have to check this setting during install)
4. Ensure vim works from the command line and you can use ssh from cygwin
5. Configure in %MERCURIAL_HOME%\Mercurial.ini (Default is C:\Mercurial\Mercurial.ini) the following:
   

   [ui]
   editor = vim
   ssh = C:\cygwin\bin\ssh.exe

Dumb trivial aside: It seems you can call cygwin commands directly without the cygwin shell if you have C:\cygwin\bin in your path. Although it might get confusing since cygwin also does path munging to make it feel more like UNIX

Now you should be able to use hg from either cygwin or the normal Windows shell properly. Enjoy.