[Dovecot] CVS to Mercurial switch
I've been meaning to switch away from CVS for a few years now, but I was never sure what I wanted to switch to, so I kept delaying it. I finally decided yesterday that Mercurial is pretty nice.
The Mercurial repository is available from http://hg.dovecot.org/ (has a nice web interface). I wrote a small Mercurial mini-howto below. I'm not a Mercurial expert yet, so if you know better ways to do some things please let me know.
The CVS repositories will still exist for a while, but they won't be updated anymore. If you notice the CVS being referenced somewhere (wiki, docs, etc.) please let me know (or fix yourself in wiki).
- Fetch the initial repository:
- ex. CVS HEAD: hg clone http://hg.dovecot.org/dovecot/
- ex. branch_1_0: hg clone http://hg.dovecot.org/dovecot-1.0/
- sieve plugin: hg clone http://hg.dovecot.org/dovecot-sieve-1.0/
The Sieve plugin currently works only with v1.0. I'll make a new "dovecot-sieve" repository for CVS HEAD later.
- Update the repository:
hg pull hg merge # only needed if you had done any changes hg update # to actually see the pulled changes
All of this can be done with fetch extension. You can enable it by adding to ~/.hgrc:
[extensions] hgext.fetch =
After that you can use "hg fetch" which does all the above 3 commands (as far as I know, haven't really tried yet).
- If you want to modify the sources, add your name to ~/.hgrc so it goes nicely into changelogs:
[ui] username = Timo Sirainen <tss@iki.fi>
You're able to "hg commit" your own changes into your repository. If you want to publish them, use "hg log" to see the changeset ID, and then use "hg export changesetid" to get patch ("hg export tip" might work too if you just want the last change(?)). You can then email the patch to Dovecot mailing list to get it merged.
With CVS the ChangeLog file was updated every 15 minutes. Now the ChangeLog file doesn't exist in the repository at all. Instead it's generated with "hg log --style=changelog" when running "make dist".
Timo Sirainen wrote:
I've been meaning to switch away from CVS for a few years now, but I was never sure what I wanted to switch to, so I kept delaying it. I finally decided yesterday that Mercurial is pretty nice.
Hi Timo,
Not complaining or anything, but I'm curious... what is it about Mercurial that you like better than Subversion - which is what pretty much every other project changes to if they change from CVS?
--
Best regards,
Charles
On 19.5.2007, at 20.28, Charles Marcus wrote:
Timo Sirainen wrote:
I've been meaning to switch away from CVS for a few years now, but
I was never sure what I wanted to switch to, so I kept delaying it. I
finally decided yesterday that Mercurial is pretty nice.Hi Timo,
Not complaining or anything, but I'm curious... what is it about
Mercurial that you like better than Subversion - which is what
pretty much every other project changes to if they change from CVS?
SVN is centralized, Mercurial is distributed. Distributed version
control systems allow a lot of nice things.
On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote:
SVN is centralized, Mercurial is distributed. Distributed version
control systems allow a lot of nice things.
Also curious here... Why Mercurial vs. TLA (I think that's what they're calling arch now?), Darcs, Monotone, or Git?
Richard
On Sat, 2007-05-19 at 14:05 -0500, Richard Laager wrote:
On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote:
SVN is centralized, Mercurial is distributed. Distributed version
control systems allow a lot of nice things.Also curious here... Why Mercurial vs. TLA (I think that's what they're calling arch now?),
Last I checked Arch / TLA seemed too complex.
Darcs,
It has its own weird diff format (don't know if you could disable it) and it can use a lot of memory.
Monotone,
I had forgotten it even existed.
or Git?
It seems a bit kludgy with all of its different commands and scripts. Also I don't really like its code. It's using standard C functions for string manipulations and in general it's using a lot with fixed size buffers. If it wasn't written by kernel developers, I'd say it's most likely full of buffer overflows. But since it is (was?), perhaps there are only a few. I don't want to risk it.
Anyway, I wanted to use a version control system that I knew was going to be usable now and would be around for a while. Mercurial seems to be used quite a lot (Mozilla, MoinMoin, Xine, ALSA, Xen), so I think it's a pretty safe choice.
I was also considering Bazaar, but since it was slower than Mercurial and didn't have any big names using it, I picked Mercurial.
Anyway, I wanted to use a version control system that I knew was going to be usable now and would be around for a while. Mercurial seems to be used quite a lot (Mozilla, MoinMoin, Xine, ALSA, Xen), so I think it's a pretty safe choice.
I was also considering Bazaar, but since it was slower than Mercurial and didn't have any big names using it, I picked Mercurial.
Interesting... thanks for taking the time to respond... :)
--
Best regards,
Charles
On Sat, 2007-05-19 at 22:31 +0300, Timo Sirainen wrote:
On Sat, 2007-05-19 at 14:05 -0500, Richard Laager wrote:
On Sat, 2007-05-19 at 20:32 +0300, Timo Sirainen wrote:
SVN is centralized, Mercurial is distributed. Distributed version
control systems allow a lot of nice things.Also curious here... Why Mercurial vs. TLA (I think that's what they're calling arch now?),
Last I checked Arch / TLA seemed too complex.
I've never played with that one.
Darcs,
It has its own weird diff format (don't know if you could disable it) and it can use a lot of memory.
Our beef with Darcs was that some operations take FOREVER to complete. We couldn't wait for the heat death of the universe to get our old history imported.
Monotone,
I had forgotten it even existed.
We're using this for Pidgin, which is why I asked.
It seems a bit kludgy with all of its different commands and scripts.
I tend to agree with this.
Also I don't really like its code. It's using standard C functions for string manipulations and in general it's using a lot with fixed size buffers.
I should start diving into the Dovecot code and learn something. ;)
Anyway, I wanted to use a version control system that I knew was going to be usable now and would be around for a while. Mercurial seems to be used quite a lot (Mozilla, MoinMoin, Xine, ALSA, Xen), so I think it's a pretty safe choice.
I was also considering Bazaar, but since it was slower than Mercurial and didn't have any big names using it, I picked Mercurial.
Ubuntu uses it, I believe.
I'm sure Mercurial is a fine choice. I should look into it sometime.
Richard
On Sat, 2007-05-19 at 22:31 +0300, Timo Sirainen wrote:
or Git?
It seems a bit kludgy with all of its different commands and scripts. Also I don't really like its code. It's using standard C functions for string manipulations and in general it's using a lot with fixed size buffers. If it wasn't written by kernel developers, I'd say it's most likely full of buffer overflows. But since it is (was?), perhaps there are only a few. I don't want to risk it.
Just out of curiosity I checked it. There are even basic string manipulation errors in their code:
~/src/git-1.5.1% grep +=.*snprintf *.c builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, commit.c: i += snprintf(parents + i, sizeof(parents) - i - 1, " %s", commit.c: i += snprintf(parents + i, sizeof(parents) - i - 1, " %s", diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, "\n"); path.c: len += vsnprintf(pathname + len, PATH_MAX - len, fmt, args);
Every single one of those is wrong. Linux kernel's snprintf() handles code like this safely, but libc doesn't.
Possibly other snprintf() uses are wrong as well.
strncpy() then:
~/src/git-1.5.1% grep strncpy *.c
builtin-log.c: strncpy(ref_message_id,
message_id,
builtin-shortlog.c: strncpy(name, realname, maxlen);
diff-lib.c: strncpy(buffer1 + len1,
p1.items[i1++].path,
diff-lib.c: strncpy(buffer2 + len2,
p2.items[i2++].path,
fast-import.c: strncpy(c->str_dat, s, len);
fast-import.c: strncpy(ident, buf, name_len);
interpolate.c: strncpy(dest, value,
valuelen);
trace.c: strncpy(trace_str, format_str, format_len);
trace.c: strncpy(trace_str + format_len, argv_str, argv_len);
correct, wrong, wrong, wrong, correct, correct
The last 3 are just stupid. They should be memcpy()s to make it clear what they intend to do.
I don't even want to start verifying the correctness of sprintf() and strcpy() calls.
Wonder if I should have Cc'd this to git list. Oh well, someone else can if they care.
On May 19, 2007, at 4:33 PM, Timo Sirainen wrote:
or Git?
It seems a bit kludgy with all of its different commands and scripts. Also I don't really like its code. It's using standard C functions
for string manipulations and in general it's using a lot with fixed size buffers. If it wasn't written by kernel developers, I'd say it's most likely full of buffer overflows. But since it is (was?), perhaps
there are only a few. I don't want to risk it.Just out of curiosity I checked it. There are even basic string manipulation errors in their code:
[newbie programmer insanity snipped]
And good luck getting it running if your isn't Linux running on an
x86 PC. I lost a good bit of hair getting it running a few weeks ago
just to get the sources of ONE PACKAGE whose maintainers decided to
adopt git as their "pet" source code control system.
*grumble*
-Dave-- Dave McGuire Port Charlotte, FL
On Sat, May 19, 2007 at 11:33:23PM +0300, Timo Sirainen wrote:
On Sat, 2007-05-19 at 22:31 +0300, Timo Sirainen wrote:
or Git?
It seems a bit kludgy with all of its different commands and scripts. Also I don't really like its code. It's using standard C functions for string manipulations and in general it's using a lot with fixed size buffers. If it wasn't written by kernel developers, I'd say it's most likely full of buffer overflows. But since it is (was?), perhaps there are only a few. I don't want to risk it.
Just out of curiosity I checked it. There are even basic string manipulation errors in their code:
I wasn't scared of the git server before, but I am now. The mercurial web CGI is dead-easy to set up, and doesn't need write access (like CVS did for locking) to be able to serve out the repo.
I also found mercurial the least kludgy of the other things I've tried, although all the extensions are starting to make the output of "hg help" a little longer than the nice simple earlier versions had ;)
On Sat, 2007-05-19 at 23:33 +0300, Timo Sirainen wrote:
Wonder if I should have Cc'd this to git list. Oh well, someone else can if they care.
I did a bit more after all:
http://marc.info/?t=117962999100002&r=1&w=2 http://marc.info/?t=117962999100004&r=1&w=2
Looks like nothing's going to change immediately, but maybe there's some hope.
On Sun, May 20, 2007 at 01:56:29PM +0300, Timo Sirainen wrote:
On Sat, 2007-05-19 at 23:33 +0300, Timo Sirainen wrote:
Wonder if I should have Cc'd this to git list. Oh well, someone else can if they care.
I've forwarded the Timo's message to the debian maintainers of git package.
Ciao
--
| Marco Nenciarini | Debian/GNU Linux Developer - Plug Member | | mnencia@prato.linux.it | http://www.prato.linux.it/~mnencia |
Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4
On Sat, 2007-05-19 at 23:33 +0300, Timo Sirainen wrote:
~/src/git-1.5.1% grep +=.*snprintf *.c builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, builtin-grep.c: len += snprintf(argptr, sizeof(randarg)-len, commit.c: i += snprintf(parents + i, sizeof(parents) - i - 1, " %s", commit.c: i += snprintf(parents + i, sizeof(parents) - i - 1, " %s", diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, diff.c: len += snprintf(msg + len, sizeof(msg) - len, "\n"); path.c: len += vsnprintf(pathname + len, PATH_MAX - len, fmt, args);
Every single one of those is wrong. Linux kernel's snprintf() handles code like this safely, but libc doesn't.
Correcting myself a bit: Actually only diff.c was wrong, in other cases they checked the overflow.
participants (6)
-
Charles Marcus
-
Dave McGuire
-
Marco Nenciarini
-
Richard Laager
-
Timo Sirainen
-
Troy Benjegerdes