From: "Kevin Grittner" on
I wrote:

> Perhaps it is as simple, though, as using the client's time
> instead of the CVS server's time -- that's one of the things I've
> seen cause problems for this sort of thing using CVS before.

I got a brief consult with a Ruby programmer here under the "if it's
less than ten minutes you don't have to schedule it through a
manager" rule. From what we can see, fromcvs scans for all entries
*after* a "previous run" time, but it isn't setting an upper bound
on time during the scan. I haven't found where it saves the time
for the lower limit of the next run, but I rather suspect that it
grabs the current time near the end of the scan. If this is an
accurate assessment, to avoid a window for lost commits, we'd have
to fix a time before we started the scan to use as the upper bound
for CVS commits to handle, and use it for the "previous run" time.

There's still the possible issue of *whose* clock we're using for
this.

Reality check: does the frequency of lost CVS commits within git
seem consistent with this theory?

-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
On Tue, Jan 19, 2010 at 16:59, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote:
>> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
>> <Kevin.Grittner(a)wicourts.gov> wrote:
>>> Magnus Hagander  wrote:
>>>
>>>>>>> the Git repository is missing parts of two non-recent commits.
>>>
>>>> We've seen this happen before.
>>>
>>> That seems like kind of a blasé attitude toward something upon which
>>> some people rely.
>>
>> For the record, I am one of those people. I use it for *all* my
>> postgresql development. And this is a serious pain.
>
> FWIW, I am in favor of rewinding and making everyone rebase, but I
> think we should do it ASAP.

Ok, I started looking at this.

First, it's not at all clear to me what Peter means wiht his comments.
But it happens to be that one of the commits he's referring to is all
the way back in August. So we'd have to rewind it all that way. Do we
really want to do that, or do we want to do a manual commit on the
repository bringing it back in sync instead? (either by knowing what's
wrong with those commits, or do a complete diff of cvs head vs git
head)


--
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: Magnus Hagander on
On Wed, Jan 20, 2010 at 09:52, Magnus Hagander <magnus(a)hagander.net> wrote:
> On Tue, Jan 19, 2010 at 16:59, Robert Haas <robertmhaas(a)gmail.com> wrote:
>> On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote:
>>> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
>>> <Kevin.Grittner(a)wicourts.gov> wrote:
>>>> Magnus Hagander  wrote:
>>>>
>>>>>>>> the Git repository is missing parts of two non-recent commits.
>>>>
>>>>> We've seen this happen before.
>>>>
>>>> That seems like kind of a blasé attitude toward something upon which
>>>> some people rely.
>>>
>>> For the record, I am one of those people. I use it for *all* my
>>> postgresql development. And this is a serious pain.
>>
>> FWIW, I am in favor of rewinding and making everyone rebase, but I
>> think we should do it ASAP.
>
> Ok, I started looking at this.
>
> First, it's not at all clear to me what Peter means wiht his comments.
> But it happens to be that one of the commits he's referring to is all
> the way back in August. So we'd have to rewind it all that way. Do we
> really want to do that, or do we want to do a manual commit on the
> repository bringing it back in sync instead? (either by knowing what's
> wrong with those commits, or do a complete diff of cvs head vs git
> head)

Actually, such a correction patch would be nice and short. Attached
for reference. Thoughts?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From: Heikki Linnakangas on
Magnus Hagander wrote:
> On Wed, Jan 20, 2010 at 09:52, Magnus Hagander <magnus(a)hagander.net> wrote:
>> On Tue, Jan 19, 2010 at 16:59, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>> On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote:
>>>> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
>>>> <Kevin.Grittner(a)wicourts.gov> wrote:
>>>>> Magnus Hagander wrote:
>>>>>
>>>>>>>>> the Git repository is missing parts of two non-recent commits.
>>>>>> We've seen this happen before.
>>>>> That seems like kind of a blas� attitude toward something upon which
>>>>> some people rely.
>>>> For the record, I am one of those people. I use it for *all* my
>>>> postgresql development. And this is a serious pain.
>>> FWIW, I am in favor of rewinding and making everyone rebase, but I
>>> think we should do it ASAP.
>> Ok, I started looking at this.
>>
>> First, it's not at all clear to me what Peter means wiht his comments.
>> But it happens to be that one of the commits he's referring to is all
>> the way back in August. So we'd have to rewind it all that way. Do we
>> really want to do that, or do we want to do a manual commit on the
>> repository bringing it back in sync instead? (either by knowing what's
>> wrong with those commits, or do a complete diff of cvs head vs git
>> head)
>
> Actually, such a correction patch would be nice and short. Attached
> for reference. Thoughts?

That seems better than rewinding the history all the way back to August.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.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: Robert Haas on
On Wed, Jan 20, 2010 at 4:27 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Magnus Hagander wrote:
>> On Wed, Jan 20, 2010 at 09:52, Magnus Hagander <magnus(a)hagander.net> wrote:
>>> On Tue, Jan 19, 2010 at 16:59, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>>> On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander <magnus(a)hagander.net> wrote:
>>>>> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
>>>>> <Kevin.Grittner(a)wicourts.gov> wrote:
>>>>>> Magnus Hagander  wrote:
>>>>>>
>>>>>>>>>> the Git repository is missing parts of two non-recent commits.
>>>>>>> We've seen this happen before.
>>>>>> That seems like kind of a blasé attitude toward something upon which
>>>>>> some people rely.
>>>>> For the record, I am one of those people. I use it for *all* my
>>>>> postgresql development. And this is a serious pain.
>>>> FWIW, I am in favor of rewinding and making everyone rebase, but I
>>>> think we should do it ASAP.
>>> Ok, I started looking at this.
>>>
>>> First, it's not at all clear to me what Peter means wiht his comments.
>>> But it happens to be that one of the commits he's referring to is all
>>> the way back in August. So we'd have to rewind it all that way. Do we
>>> really want to do that, or do we want to do a manual commit on the
>>> repository bringing it back in sync instead? (either by knowing what's
>>> wrong with those commits, or do a complete diff of cvs head vs git
>>> head)
>>
>> Actually, such a correction patch would be nice and short. Attached
>> for reference. Thoughts?
>
> That seems better than rewinding the history all the way back to August.

It seems pretty horrible to me. That means we'll have a range of
times 5 months long for which the git repository doesn't match CVS.

Admittedly, I understand that this is going to be extremely painful
for anyone who (like Heikki) has to manage a substantial private
branch.

I haven't been in a hurry to see us move to git because the git mirror
is, for most purposes, just as good. But if the git mirror is going
to start sucking, then I'm in a hurry. The way I used to work before
I learned git seems laughable now, and I do NOT want to go back.

....Robert

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