Thread: Re: [COMMITTERS] pgsql: pgindent run for 9.0, second run
On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian@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
Robert Haas wrote: > On Tue, Jul 6, 2010 at 3:19 PM, Bruce Momjian <momjian@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
Andrew Dunstan <andrew@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
On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Andrew Dunstan <andrew@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
On Tue, Jul 20, 2010 at 18:13, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: >> Andrew Dunstan <andrew@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/
Kevin Grittner wrote: > Andrew Dunstan <andrew@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?) > > > The trouble is that they don't have a common git commit history. I suspect we'll just totally mangle the repo if we try that. But anyone can experiment if they want to. My repo is available on <git://github.com/oicu/pg-cvs-mirror.git> or <http://github.com/oicu/pg-cvs-mirror.git> Or people can just use that repo. I have four buildfarm members running off it daily, and I run a daily health check on it against CVS. I can undertake to maintain it until at least the middle of August (after which I'll be travelling for a few weeks). cheers andrew
Robert Haas <robertmhaas@gmail.com> wrote: > It would result in a massive merge commit and the duplication of > the entire history. Ah, well, if the two repositories don't share the same IDs, it a clear no-go. Now that I think about it, it would be a bit much to expect those to match on independent conversions from CVS. How is this going to play out when we do the "official" conversion to git? Will those of us on repositories based off of git.postgresql.org be faced with similar issues, or are we using the repo there as the base for the conversion? -Kevin
On Tue, Jul 20, 2010 at 18:32, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Robert Haas <robertmhaas@gmail.com> wrote: > >> It would result in a massive merge commit and the duplication of >> the entire history. > > Ah, well, if the two repositories don't share the same IDs, it a > clear no-go. Now that I think about it, it would be a bit much to > expect those to match on independent conversions from CVS. > > How is this going to play out when we do the "official" conversion > to git? Will those of us on repositories based off of > git.postgresql.org be faced with similar issues, or are we using the > repo there as the base for the conversion? No, it will be a completely new repository. Those with the old one will need to extract a patch from that and then apply it to the new one. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Tue, Jul 20, 2010 at 18:13, Robert Haas <robertmhaas@gmail.com> wrote: > >> On Tue, Jul 20, 2010 at 12:01 PM, Kevin Grittner >> <Kevin.Grittner@wicourts.gov> wrote: >> >>> Andrew Dunstan <andrew@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 :-) > > Given that the repo's remaining lifetime is measured in weeks, that seems reasonable. cheers andrew