HW+ / DXR3 device driver for Linux

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.

> 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).

> 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.

Hi Ville,

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 
  http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan

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 
have mercurial...

All this is certainly not required, but I think it would make my life 
somewhat easier.


Cheers,

Nicolas

On Thursday 21 February 2008, Nicolas Boullis wrote:
> Hi Ville,
>
> On Wed, Feb 20, 2008 at 09:53:24AM +0200, Ville Skyttä wrote:
> >
> > 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?

Some yes, but pretty limited with both.  Mostly just tracking a single 
upstream repository with both, occasional merges and local commits.  And some 
experience with working on a couple of different local "topic" branches with 
git.

> I had the idea that git was 
> rather complex to use, while I find mercurial quite straightforward.

For me the whole distributedness of both and what results from it was (and 
still very much is) the thing that took most time getting accustomed to.  I 
didn't find either really more complex than the other, although ISTR git has 
many more "low level" repository things exposed to end users than hg.

> But then I'd like to avoid changing configure.in and modules/Makefile
> twice for each release.

A bit off topic, but perhaps this would be a good time to also think about 
splitting em8300 into utils and modules, as modules tend to be significantly 
more often changed than utils.

> 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
> have mercurial...

Perhaps Mercurial's hooks could be used to automatically inject the desired 
version identifiers into place in desired files, eg. using sed?  
http://hgbook.red-bean.com/hgbookch10.html

Hi Ville and others,

As for mervurial vs. git, there are 2 possible ways. Either I decide to 
switch to mercural anyway, or I decide to give git a try, and in a 
not-so-near future I make a choice.

Well, it seems to me that switching from CVS to a better VCS will make 
things easier for me (and perhaps finally realize the long-promised 
autoconfiguration, who knows). So, the sooner the better. Hence I just 
decided to switch now to mercurial. I may decide to whange again to git 
at some point in the future.

For those who are interested, my repository is served at
  http://dxr3.sourceforge.net/hg/em8300-nboullis/

Those who want to contribute are welcome to either
  - serve their repositories somewhere I can pull their changesets
  - export their changesets and send them by mail

On Sat, Feb 23, 2008 at 10:12:32PM +0200, Ville Skyttä wrote:
> 
> A bit off topic, but perhaps this would be a good time to also think about 
> splitting em8300 into utils and modules, as modules tend to be significantly 
> more often changed than utils.

This would certainly be a good thing to do, but I think the two tasks 
are unrelated.
I did not want to lose the history, so I converted the CVS repository to 
a mercurial one (and hacked the converted repository to deal with a 
few problems, as character encoding issues, misplaced tags or missing 
merges).
I think it is now possible to split things by cloning the repository and 
removing the non-relevant files in each.


> Perhaps Mercurial's hooks could be used to automatically inject the desired 
> version identifiers into place in desired files, eg. using sed?  
> http://hgbook.red-bean.com/hgbookch10.html

I don't think so. If you mean using hooks to modify the changesets 
when they are committed/pushed/pulled/..., I don't this it is possible 
nor desirable.
If you mead using hooks to alter the working dir on updates, this 
certainly is possible, but relies on the fact that every user will setup 
this hook. I think using the keyword extension is more reliable, since 
it looks easier for the users.

Anyway, I just committed a changeset that implement versionning for the 
modules; comments are welcome.


Cheers,

Nicolas