Plan B ...

Friday, October 8. 2010

I had hoped that all the buildfarm members would be able to run git, and we could just forget about CVS. Sadly, this turns out not to be the case. Plan B, therefore, is to run git-cvsserver. This turns out to have a few oddities, in particular in treating a git branch as a CVS module. This mean I've had to make some adjustments to the buildfarm client which expects to deal with a single CVS module called 'pgsql'.

We've had some discussions over how to restrict what can be checked out, mainly because git-cvsserver creates a large database for each branch or head that is checked out, so we really only want to support a small number of branches (i.e. those that the buildfarm is interested in). I think we have managed to resolve that.

Initial setup of these databases takes quite a bit of time. I wonder if the git-cvsserver author(s) ever tried it on a seriously large repository. On my setup, creating the initial PostgreSQL databases takes about 30 minutes per branch. Once it's set up it's quite fast, however.

There will be a few limitations:

CVS export mode is not supported by git-cvsserver. That's no great loss

There are no .cvsignore files any more, at least in the master branch, so buildfarm owners will have to make sure they keep their repos really clean, and vpath builds probably won't work. And no, we can't use the .gitignore files that have been set up - at least not easily and I'm not inclined to put much effort into trying.

The changed files will be reported to the buildfarm web site, but the links there will be nonsense, at least for now. git-cvsserver invents a CVS revision number for the files, but the only place it stores the link from that to the git filehash and commithash values is in its private database. We'd need a way to get that table to the buildfarm, or a way of having the buildfarm server query it on the fly over a SOAP interface or similar. I'm not sure if that's worth doing, although it would not be hard. I wonder how many people follow those links.

I'm going to revive my "quoll" buildfarm member to test all this out daily for a little while.

Posted by Andrew Dunstan in PostgreSQL at 19:58 | Comments (5) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

For the curious among us...why couldn't those machines run git? I was under the impressions that git was pretty much universal by now.

#1 Joshua Kugler (Homepage) on 2010-10-08 21:57 (Reply)

On the one we know of for sure, git is core dumping for some reason. It's running OpenBSD 4.2 on a Sparc64 platform, which is probably not a very common combination. I'm also not sure about some other platforms like ARM and other processors, nor lesser used operating systems. Git is known to run on common platforms, but not necessarily all.

#1.1 Andrew Dunstan on 2010-10-08 22:17 (Reply)

Ah, OK...that makes sense. But it's open source! You can fix it yourself! <img src="/andrew/templates/default/img/emoticons/smile.png" alt=":-)" style="display: inline; vertical-align: bottom;" class="emoticon" /> Heh...just teasing. Wow...Pg on ARM...that sounds cool.

#1.1.1 Joshua Kugler (Homepage) on 2010-10-08 22:39 (Reply)

So ... could we have a stack trace from the core dump?

#1.1.2 Tom Lane on 2010-10-09 08:30 (Reply)

Here's the top of the trace I was shown: 
 
#0 0x00000000001dfe3c in recv_sideband (me=0x2ff638 "fetch-pack", in_stream=5, out=Cannot access memory at address 0x48a1bccc) at sideband.c:30 
 
 
I couldn't see anything obvious, but maybe you can. We tried a couple of different things, like using strncpy() instead of memcpy and making PREFIX a static char[] instead of using #define, all to no avail.

#1.1.2.1 Andrew Dunstan on 2010-10-09 18:13 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. Wiki format allowed
	Remember Information? Subscribe to this entry