If you say so. I'll make a build and check.

There are PDBs with some sort of content at least. It was not obvious how MSVS is supposed to eat them when debugging, and I was to lazy to read docs just then. Potentially working at least.

I'm not aware of any regressions _against earlier 7.8 builds_ right now, so I think I'll build a beta tonight if no one protests.

The current Pikefarm builds from my machine is not usefull to debug this due to clock scew. So:

#### Making dynamic: modules/Mysql Compiling modules/Mysql/mysql.c Compiling modules/Mysql/result.c B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(688) : error C2143: syntax error : missing ';' before 'type' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(689) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(689) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(690) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(690) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(697) : error C2143: syntax error : missing ';' before 'type' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(707) : error C2065: 'r' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(708) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(708) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(710) : error C2065: 'res' : undeclared identifier

*snip*

Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:

Which goes to show that the 7.9 development should be happening in git ASAP. Is there anything left on the todo-list for that switchover? Is there a list?

There still is a final history-rewrite pending. But that shouldn't stop any new development. It would mean at some point in time we would need to rebase once (to get back in sync with the new & improved history).

However, the git repository running the mirror is running very stable and hasn't hickupped for the past 11 months. IMO it is ready for production, opening an official 7.9 branch there takes about a second. I'd guess that adapting pikefarm to read from the git repository is still on the todo list.

I believe we'll want to do a reexport with a cvsps containing mast's patches first as well.

Ah, yes. Because of the coming migration to git at Roxen, I've been hacking a bit the last months on cvsps and git-cvsimport to make them work decently (I started on it before I noted the bit at the end of git-cvsimport(1) enumerating all its serious faults). I got most things sorted out now, including vendor branch mirroring etc.

I've pushed my patches to srb's repo at pike-git.lysator.liu.se:cvsps.git/.git

If cvsps/git-cvsimport is used for the pike repo then I strongly suggest using my patched tools, but I got the impression that other tools are used since it's based on Comstedts svn export, right?

Btw, in my conversion of (mainly) the Roxen Webserver repo, I've done some other things which I think are nice. One is to include the cvs revisions in old commit messages, since cvs commits might refer to other commits that way. E.g:

commit dbe28d2 Author: Henrik Grubbström grubba@grubba.org Date: Fri May 15 14:30:26 2009 +0200

First go at automatic database backups. Currently disabled by ENABLE_DB_BACKUPS.

[subtabs.pike 1.18, DBManager.pmod 1.86]

server/config_interface/dbs/subtabs.pike | 21 + server/etc/modules/DBManager.pmod | 595 ++++++++++++++++++++++++++++-- 2 files changed, 577 insertions(+), 39 deletions(-)

Another is to make tag names look nicer by converting "_" to "-" or ".", e.g. "roxen_5_0_366" in cvs becomes "roxen-5.0.366" in git.

I can of course provide my scripts and stuff for that if someone wants it.

...

If cvsps/git-cvsimport is used for the pike repo then I strongly suggest using my patched tools, but I got the impression that other tools are used since it's based on Comstedts svn export, right?

It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.

A good plan. By the way, the svn repository is currently a bit out of date due to the CVS rsync on eureka not working, but I think it should be fine to use what exists now, and pull all changesets after that directly from CVS. If not, just let me know and I'll resync the svn repo (assuming the rsync functionality has been reestablished).

Tonight that is, because I don't have enough credentials to do it from where I am apparently.

Ok, then the current repo (which is complete up to January 2009) should be sufficient for a rebase.

Do you, by any chance, have scripts which checkout a revision from the SVN repository and also checkout the corresponding revision from a CVS repository?

Nope, sorry. The date of the commit should be usable, although I'm unsure if a grouped set of commits use the date of the first CVS commit or the last one (that's part of cvs2svn:s functionality).

Thanks. However, I ran into this error, which I haven't seen before:

Error summary: ERROR: A CVS repository cannot contain both /cvsroot/Pike/nt-tools/tools/sdl-config,v and /cvsroot/Pike/nt-tools/tools/Attic/sdl-config,v ERROR: A CVS repository cannot contain both /cvsroot/Pike/nt-tools/tools/sdl-config.disabled,v and /cvsroot/Pike/nt-tools/tools/Attic/sdl-config.disabled,v Exited due to fatal error(s).

Did someone actually go fiddling with these ,v files, or is this a problem with the rsync?

Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

...

It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.

A good idea, but beware that that doesn't necessarily give the correct view of what a real cvs checkout gave at that time, since the ,v files have been moved around etc. I've spent some time reconstructing such

I realise that. The logic verifying the checkouts needs to selectively ignore things like that. The most likely errors I want to catch are simple import errors which result(ed) in corrupted commits (e.g. all the missing CRs in the SVN repository which broke all binary files (like gifs)).

Yes, there is a list.