Prev: Parsing of aggregate ORDER BY clauses
Next: psql \conninfo command (was: Patch: psql \whoami option)
From: Robert Haas on 19 Jul 2010 23:23
On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian(a)postgresql.org> wrote:
> Log Message:
> -----------
> pgindent run for 9.0, second run

It appears that the <expletive> git mirror has deduced the wrong
contents for this commit. Apparently as a result, when I build from
git master, the dblink regression tests fail.

Can someone please fix this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Andrew Dunstan on 20 Jul 2010 00:14


Robert Haas wrote:
> On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian(a)postgresql.org> wrote:
>
>> Log Message:
>> -----------
>> pgindent run for 9.0, second run
>>
>
> It appears that the <expletive> git mirror has deduced the wrong
> contents for this commit. Apparently as a result, when I build from
> git master, the dblink regression tests fail.
>
> Can someone please fix this?
>
>

I despaired of this repo being anything like reliable months ago. AFAIK
it is using a known to be broken version of fromcvs.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on 20 Jul 2010 12:01
Andrew Dunstan <andrew(a)dunslane.net> wrote:

> I despaired of this repo being anything like reliable months ago.
> AFAIK it is using a known to be broken version of fromcvs.

Could we have it pull (using git) from the repo you have working
correctly? (Or would that be too Rube Goldbergesque?)

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 20 Jul 2010 12:13
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
<Kevin.Grittner(a)wicourts.gov> wrote:
> Andrew Dunstan <andrew(a)dunslane.net> wrote:
>
>> I despaired of this repo being anything like reliable months ago.
>> AFAIK it is using a known to be broken version of fromcvs.
>
> Could we have it pull (using git) from the repo you have working
> correctly? �(Or would that be too Rube Goldbergesque?)

It would result in a massive merge commit and the duplication of the
entire history. The correct solution is probably to (a) install
Andrew's fixed version of the import tool on the server and (b) rewind
the history on the server so it reimports all the subsequent commits.
Sometimes doing only (b) is sufficient to correct the problem, since
the tool seems rather sensitive to ephemeral states of the
respository.

Unfortunately, (a) has not happened. Magnus seems to feel that Andrew
has not provided sufficient details about which version he should be
running and whether it will likely break anything, and I gather that
Andrew feels otherwise. Figuring out who is right and who is wrong
and what to do about it is above my pay grade, but it would be really
nice if someone could get this straightened out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Magnus Hagander on 20 Jul 2010 12:20
On Tue, Jul 20, 2010 at 18:13, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner
> <Kevin.Grittner(a)wicourts.gov> wrote:
>> Andrew Dunstan <andrew(a)dunslane.net> wrote:
>>
>>> I despaired of this repo being anything like reliable months ago.
>>> AFAIK it is using a known to be broken version of fromcvs.
>>
>> Could we have it pull (using git) from the repo you have working
>> correctly? �(Or would that be too Rube Goldbergesque?)
>
> It would result in a massive merge commit and the duplication of the
> entire history. �The correct solution is probably to (a) install
> Andrew's fixed version of the import tool on the server and (b) rewind
> the history on the server so it reimports all the subsequent commits.
> Sometimes doing only (b) is sufficient to correct the problem, since
> the tool seems rather sensitive to ephemeral states of the
> respository.
>
> Unfortunately, (a) has not happened. �Magnus seems to feel that Andrew
> has not provided sufficient details about which version he should be
> running and whether it will likely break anything, and I gather that
> Andrew feels otherwise. �Figuring out who is right and who is wrong
> and what to do about it is above my pay grade, but it would be really
> nice if someone could get this straightened out.

Meh, who cares who's right or wrong :-)

My main point is I am unsure if this may have any adverse effects, and
I haven't had the time to investigate if it doesor not. Previously
we've just applied a manual correction patch to bring the branch tip
up to the correct state, which is supposedly good enough for the users
of the git server. In which case, someone just needs to proide said
patch :-)

--
�Magnus Hagander
�Me: http://www.hagander.net/
�Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2
Prev: Parsing of aggregate ORDER BY clauses
Next: psql \conninfo command (was: Patch: psql \whoami option)