Git out of sync vs. CVS
in [PgSql]
|
From: Heikki Linnakangas on 20 Jan 2010 10:13 Robert Haas wrote: > On Wed, Jan 20, 2010 at 4:27 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Magnus Hagander wrote: >>> 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 won't object to rewinding, it should be fairly painless to rebase. > 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. My feelings exactly. I'm not in a hurry to switch because the mirror is good enough for me. But if *I* have to spend time fixing the mirror every few weeks, I'm not happy. Magnus has been kind enough to handle the last mirror troubles, but I believe hë́ shares the feeling. -- 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: Tom Lane on 20 Jan 2010 11:17 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Magnus Hagander wrote: >> 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. +1 ... I'm just an interested observer not a user of the git repository, but this approach seems far less work for everyone concerned. regards, tom lane -- 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 21 Jan 2010 05:02 On Wed, Jan 20, 2010 at 15:36, Robert Haas <robertmhaas(a)gmail.com> wrote: > 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. Yes. But how bad is that really the way we do things now? It still works perfectly fine for development against HEAD, which believe is what most people are using it for at this point. (As long as somebody keeps finding these things when they happen, that is) I'm going to do the fixup for now. We can always rewind past that one later if we have to, it's not like it's going to get any worse. > Admittedly, I understand that this is going to be extremely painful > for anyone who (like Heikki) has to manage a substantial private > branch. Well, git actually picks that up reasonably well these days, but it's still a bit of a pain. Also, all the links people have posted will no longer be valid, etc. > 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. I can only agree with this. I would very much like to see that discussion opened again - after we've released 9.0. But for that reason, it'd be good if we could take care of the issues listed on the wiki page before that happens :-) -- 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 21 Jan 2010 05:09 On Tue, Jan 19, 2010 at 21:07, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > 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? Well, supposedly all our servers are synced with NTP. I know the main cvs server is, and the git server is, but it goes past the anoncvs server which is a hub.org server so I don't know for sure there - but I think it is? So I don't think it's the machines-out-of-sync issue. Or at least the window for that is *really* small. -- 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: Tom Lane on 21 Jan 2010 09:54
Magnus Hagander <magnus(a)hagander.net> writes: > On Tue, Jan 19, 2010 at 21:07, Kevin Grittner >> Reality check: does the frequency of lost CVS commits within git >> seem consistent with this theory? > Well, supposedly all our servers are synced with NTP. I know the main > cvs server is, and the git server is, but it goes past the anoncvs > server which is a hub.org server so I don't know for sure there - but > I think it is? So I don't think it's the machines-out-of-sync issue. > Or at least the window for that is *really* small. I have noticed that CVS operations (at least from the user's viewpoint) work in local time. So even if the clocks are synced, a different TZ setting could conceivably lead to issues. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |