Git out of sync vs. CVS
in [PgSql]
|
From: "Kevin Grittner" on 17 Jan 2010 19:53 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. When we (at Wisconsin State Courts) were using CVS and had scripts to automatically merge changes from one branch to another, we saw this sort of thing unless people were very careful to grab a timestamp in the past for their ranges and use it throughout the script. Perhaps the script is just not careful enough? (Said in total ignorance of what the PostgreSQL process here actually is....) -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 19 Jan 2010 10:44 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. It has been brought up before. Nobody has come up with a completely safe way to do it, because CVS simply doesn't have the capabilities required. And yes, it is annoying to have to deal with the issues with CVS at the same time as people keep saying CVS is perfectly fine. It's not. It's just that we are doing our best to work around the issues in it, and sometimes that leads to these issues. > When we (at Wisconsin State Courts) were using CVS and had scripts to > automatically merge changes from one branch to another, we saw this > sort of thing unless people were very careful to grab a timestamp in > the past for their ranges and use it throughout the script. Perhaps > the script is just not careful enough? (Said in total ignorance of > what the PostgreSQL process here actually is....) That would be one way. However, AFAIK the tool we use (fromcvs) doesn't support this. If somebody were to extend the tool with that, it would be much appreciated. It's a Ruby tool though, so there's not a thing I can do about it myself... And it's basically undocumented. But yes, if we do that and set the timestamp far enough back in time, that should make it "reasonably safe". Given how long some operations can take ((C) year change, release tagging IIRC, stuff like that), this has to be a fairly large number, which means the git mirror will lack even further behind. But if that's what we have to pay to make it safe, I guess we should... The time would have to be long enough to cover any cvs commit including potential network slowness during it etc. -- 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: Robert Haas on 19 Jan 2010 10:59 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. ....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
From: Magnus Hagander on 19 Jan 2010 11:02 On Tuesday, January 19, 2010, 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. Got time to figure out exactly how far to rewind? /Magnus -- 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: Aidan Van Dyk on 19 Jan 2010 11:03
* Magnus Hagander <magnus(a)hagander.net> [100119 10:44]: > > When we (at Wisconsin State Courts) were using CVS and had scripts to > > automatically merge changes from one branch to another, we saw this > > sort of thing unless people were very careful to grab a timestamp in > > the past for their ranges and use it throughout the script. Perhaps > > the script is just not careful enough? (Said in total ignorance of > > what the PostgreSQL process here actually is....) > > That would be one way. However, AFAIK the tool we use (fromcvs) > doesn't support this. If somebody were to extend the tool with that, > it would be much appreciated. It's a Ruby tool though, so there's not > a thing I can do about it myself... And it's basically undocumented. > > But yes, if we do that and set the timestamp far enough back in time, > that should make it "reasonably safe". Given how long some operations > can take ((C) year change, release tagging IIRC, stuff like that), > this has to be a fairly large number, which means the git mirror will > lack even further behind. But if that's what we have to pay to make it > safe, I guess we should... The time would have to be long enough to > cover any cvs commit including potential network slowness during it > etc. Well, when I was running my conversion, I took a "cheap" way, I just rsynced twice (with a delay, I don't remember how long I decided was long enough) and made sure the 2nd rsync didn't do anything, before I let fromcvs at the copy of CVSROOT. Sure, it's not perfect either, I based that on the hope that no "single CVS commit" would have a period of $X of inactivity on the CVSROOT. Of course, that could all be useless (for my PG conversion) if the PG CVSROOT that was an unstable point-in-time copy of the real CVSROOT, but I was rsyncing CVSROOT of other projects too, so I needed it for my own conversions... a. -- Aidan Van Dyk Create like a god, aidan(a)highrise.ca command like a king, http://www.highrise.ca/ work like a slave. |