Replacing the venerable CVS

[Nicolas Boullis]

Hi all,

I have long been thinking about replacing the venerable CVS with some
more modern VCS.
I have tried subversion a few times, but never really understood how it
works. (To be honnest, I did not insist much.)

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.

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. And
also some useful versionning of unreleased checkouts.


All comments and suggestions are welcome.


Cheers,

Nicolas

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Ville Skyttä]

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.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Nicolas Boullis]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Ville Skyttä]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel

[Nicolas Boullis]

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Dxr3-devel mailing list
Dxr3-devel@...
https://lists.sourceforge.net/lists/listinfo/dxr3-devel