Re: Git out of sync vs. CVS - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Git out of sync vs. CVS
Date
Msg-id 9837222c1001190744h53deef05n3e208a2cbd8ab8da@mail.gmail.com
Whole thread Raw
In response to Re: Git out of sync vs. CVS  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Git out of sync vs. CVS  (Robert Haas <robertmhaas@gmail.com>)
Re: Git out of sync vs. CVS  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Git out of sync vs. CVS  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
<Kevin.Grittner@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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Next
From: Alex Hunsaker
Date:
Subject: Re: attoptions