Re: buildfarm building all live branches from git

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buildfarm building all live branches from git
Date: 2010-05-05 12:29:01
Message-ID: 4BE1648D.1000900@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex Hunsaker wrote:
> On Mon, May 3, 2010 at 14:04, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> [ Awesome work getting buildfarm support for git ]
>>
>
>
>> Note, this is running from my test git repo, not the community's repo.
>>
>
> BTW +1 for gitting (heh, git puns are fun) a good git repo published.
> Ive given up trying to trust it for back branches and always either go
> to release tarballs or cvs.
>

The repo I have created is currently available publicly at
<http://github.com/oicu/pg-cvs-mirror> and you can clone
<git://github.com/oicu/pg-cvs-mirror.git>

It is kept fairly up to date (mostly within an hour of the community CVS
repo) and checked daily for validity against all live branches.

>
>> Sadly, that means its change
>> links will be broken - I'm not exactly sure what gets hashed to provide a
>> commit ID in git, but the IDs don't match between these two repos.
>>
>
> Yeah, git basically hashes *everything* including the previous
> commits. So if one commit is different in the repo all the commits
> after that will have a different hash :-(
>
>

Right. However, I have in fact solved this issue by allowing buildfarm
members to specify a url to show changesets. In tha case of quoll this
is set thus

scm_url => 'http://github.com/oicu/pg-cvs-mirror/commit/',

and its change links now do the right thing. The new client code should
be released in about a week.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-05-05 13:46:15 Re: max_standby_delay considered harmful
Previous Message Robert Haas 2010-05-05 10:23:12 Re: max_standby_delay considered harmful