Prev: Parsing of aggregate ORDER BY clauses
Next: psql \conninfo command (was: Patch: psql \whoami option)
From: "Kevin Grittner" on 20 Jul 2010 12:32
Robert Haas <robertmhaas(a)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

--
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:34
On Tue, Jul 20, 2010 at 18:32, Kevin Grittner
<Kevin.Grittner(a)wicourts.gov> wrote:
> Robert Haas <robertmhaas(a)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/

--
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 12:42


Magnus Hagander wrote:
> 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 :-)
>
>

Given that the repo's remaining lifetime is measured in weeks, that
seems reasonable.

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

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