Re: Git out of sync vs. CVS

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us>, peter_e <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Git out of sync vs. CVS
Date: 2010-01-19 15:44:11
Message-ID: 9837222c1001190744h53deef05n3e208a2cbd8ab8da@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2010-01-19 15:51:40 Re: attoptions
Previous Message Tom Lane 2010-01-19 15:25:46 Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)