On Wed, Feb 20, 2008 at 09:53:24AM +0200, Ville Skyttä wrote:
> On Wednesday 20 February 2008, Nicolas Boullis wrote:
> > A few days ago, I was introduced to mercurial, and began to envoy it. As
> > far as I am concerned, it just works. To quetsion to ask, everything
> > seems so easy. Hence, I'm now seriously considering to switch the
> > development of the em8300 driver (and related tools) to mercurial.
> Sounds like a good idea. But if you have time to look into another VCS, git
> would be worth a look too. hg and git are very similar and both do the job
> great, in my limited experience in a nutshell I think I'd recommend hg for
> projects that have developers working on Windows, and git for Linux-only
> ones. Upstream kernel obviously uses git, and since there are plans/hopes to
> have em8300 merged at some point, git could result in a bit less work there.
That sounds like a good point! ;-)
Do you have some experience with both? I had the idea that git was
rather complex to use, while I find mercurial quite straightforward.
> > There still are a few points I'd like to fix, as I'd like to have
> > automatic generation of the changelog, out of the repository's logs.
> A Makefile target something like this should do the trick:
> ChangeLog: $(ALL_FILES_TRACKED_IN_CHANGELOG)
> hg log --style changelog > $@
> It seems to group/indent successive entries by committer somewhat weirdly
> though (mercurial 0.9.4 here).
I already knew about "hg log --style changelog".
The thing I don't know is what entries are listed. For example if I
rebuild an "old" release, will it list more recent entries? And will it
list entries for old branches that were never merged?
(Hmmm... looks like --follow is good for me.)
> > And also some useful versionning of unreleased checkouts.
> Changeset number of the checkout could be useful. But it's the changeset
> number of the local repository and doesn't map directly to the centralized
> one's if there are local committed changes.
I thought about using the changeset hash, as it is stable accross
repositories, and permits to identify unofficial changesets.
But mercurial does not natively support keywords as CVS does. Using a
not-so-common extension probably is not a good idea, since I guess most
users will not configure their mercurial. A solution might be to use the
trick shown in
But then I'd like to avoid changing configure.in and modules/Makefile
twice for each release. It might be possible to extract the full version
number out of a tag. But then it has to work with a generated tarball
(with "make dist") that lacks the .hg directory and for users who don't
All this is certainly not required, but I think it would make my life