Что произойдет, если репозиторий зависимостей будет удален на GitHub?


9
  • У меня есть хранилище GitHub, A.
  • Репозиторий B - это еще один проект с открытым исходным кодом, который принадлежит кому-то другому.
  • Хранилище A зависит от хранилища B (хранилище B является подмодулем A).

Если владелец репозитория B решит удалить этот репозиторий, пользователи больше не смогут успешно клонировать / оформить / собрать мой репозиторий.

Должен ли я превентивно форк B использовать в качестве резервной копии на случай, если владелец решит удалить его? Считается ли это опасной ситуацией или как она обычно обрабатывается для проектов с открытым исходным кодом?


3
Поправьте меня, если я что-то упустил, но если A зависит от B, то каждый раз, когда кто-то хочет построить A, он должен клонировать и A, и B, так что даже если B был удален, каждый, кто использует A, вероятно, имеет копию B (включая историю) валяется в их системе, потому что git - это DVCS, так что, скорее всего, вы можете создать форк задним числом. Правильно? Или это какая-то другая «зависимость»?

Это нормальная зависимость от репо. Но в основном я поддерживаю A. Он стабилен и не ведет активной разработки (только случайные исправления), поэтому для поддержания чистоты моего маленького SSD я сохраняю код только на GitHub. Поэтому я чувствую, что это опасная ситуация, так как у A будут проблемы, если владелец B решит удалить B, а у меня нет вытесняющего форка.

3
Вилы бесплатны. Если это поможет вам спать по ночам, сделайте это.

Ответы:


3

Если владелец репозитория B решит удалить этот репозиторий, пользователи больше не смогут успешно клонировать / оформить / собрать мой репозиторий.

Если зависимый код «repo B» исчезает:

  • Все пользователи смогут успешно клонировать ваш репо.
  • Существующие пользователи, вероятно, будут иметь локальную копию репозитория B и продолжат сборку. Клонированные репозитории, как правило, не удаляются, если источник удаляется, если только пользователь не попытался специально настроить этот сценарий. Поскольку Git является DVCS, он предназначен для защиты от подобных вещей.
  • Новые пользователи не смогут создать ваше хранилище, пока не получат копию хранилища B откуда-нибудь. Вы были бы в этой лодке, так как вы не храните резервную копию.

Должен ли я превентивно форк B использовать в качестве резервной копии на случай, если владелец решит удалить его?

Да.

Считается ли это опасной ситуацией или как она обычно обрабатывается для проектов с открытым исходным кодом?

Да, это опасная ситуация в зависимости от популярности / распределения / зеркал зависимого репо и того, насколько важно ваше репо для вас. Если это важно для других, у них (надеюсь) уже есть резервная копия как вашего репо, так и репо.

Обратите внимание, что вы можете подключить его на GitHub к своей учетной записи и не клонировать его на свой SSD, чтобы не занимать место. Также имейте в виду, что этот вариант резервного копирования зависит от того, что ничего не происходит с серверами GitHub или ваша учетная запись не подвергается риску; только вы можете определить степень избыточности, которая является адекватной.

Учитывайте количество кода, на которое вы полагаетесь, его популярность, сложность его воспроизведения и стоимость надежного хранения. После рассмотрения этой оценки риска, сделайте соответствующее резервное копирование.


Поскольку стоимость, по-видимому, является фактором вашей ситуации, поскольку вы не хотите тратить больше на больший SSD, вот список дешевых вариантов резервного копирования:

  1. Очевидно, раскошелиться на GitHub, так как он абсолютно бесплатный. GitHub будет использовать дедупликацию, поэтому стоимость для них будет минимальной.
  2. Локально (бесплатно), старые вращающиеся жесткие диски или флешки. Также вы, возможно, уже платите за бесплатное резервное копирование в облачном хранилище через своего интернет-провайдера или оператора сотовой связи.
  3. Удаленно (бесплатно), множество бесплатных вариантов облачного резервного копирования или попросите друга.
  4. Удаленно ($) купите тарифный план Usenet за ГБ и загрузите его в Usenet (~ 25 ГБ за 10 USD)
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.