Re: Interesting post-mortem on a near disaster with git
От | Andrew Dunstan |
---|---|
Тема | Re: Interesting post-mortem on a near disaster with git |
Дата | |
Msg-id | 514F7C94.1060103@dunslane.net обсуждение исходный текст |
Ответ на | Re: Interesting post-mortem on a near disaster with git (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Interesting post-mortem on a near disaster with git
|
Список | pgsql-hackers |
On 03/24/2013 06:06 PM, Michael Paquier wrote: > On Mon, Mar 25, 2013 at 12:52 AM, Tom Lane <tgl@sss.pgh.pa.us > <mailto:tgl@sss.pgh.pa.us>> wrote: > > Over the weekend, KDE came within a gnat's eyelash of losing *all* > their authoritative git repos, despite having seemingly-extensive > redundancy. Read about it here: > http://jefferai.org/2013/03/24/too-perfect-a-mirror/ > > It is really great that KDE people are actually sharing this > experience. This is really profitable for other projects as well as > individuals. > And thanks for sharing it here. > > > We should think about protecting our own repo a bit better, especially > after the recent unpleasantness with a bogus forced update. The idea > of having clones that are deliberately a day or two behind seems > attractive ... > > Just an idea here: why not adding a new subdomain in postgresql.org > <http://postgresql.org> for mirrors of the official GIT repository > similar to the buildfarm? > People registered in this service could publish themselves mirrors and > decide by themselves the delay their > clone keeps with the parent repo. The scripts used by each mirror > maintainer (for backup, sync repo with > a given delay) could be centralized in a way similar to buildfarm code > so as everybody in the community could > use it and publish it if they want. > > Also, the mirrors published should be maintained by people that are > well-known inside the community, > and who would not add extra commits which would make the mirror > out-of-sync with the parent repo. > > Such an idea is perhaps too much if the point is to maintain 2-3 > mirrors of the parent repo, but gives > enough transparency to actually know where the mirrors are and what is > the sync delay maintained. This strikes me as being overkill. The sysadmins seem to have it covered. Back when we used CVS for quite a few years I kept 7 day rolling snapshots of the CVS repo, against just such a difficulty as this. But we seem to be much better organized with infrastructure these days so I haven't done that for a long time. cheers andrew
В списке pgsql-hackers по дате отправления: