Re: Git out of sync vs. CVS

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Git out of sync vs. CVS
Дата
Msg-id 9837222c1001190744h53deef05n3e208a2cbd8ab8da@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Git out of sync vs. CVS  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Git out of sync vs. CVS
Re: Git out of sync vs. CVS
Re: Git out of sync vs. CVS
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: attoptions