Есть ли вредные команды, использующие GIT и HG - PullRequest
5 голосов
/ 30 апреля 2011

Я преподаю HG своим студентам, так как это хороший PlayCSol DVCS (не такой мощный, как GIT, но простой для начала работы с тривиальными концепциями). Я использую HG, потому что кажется, что очень трудно уничтожить предыдущие записи (за исключением hg rollback), поэтому у вас всегда есть шанс вернуться в поезд, не уничтожив важные данные. Но мне недавно стало интересно:

  • это правда?
  • обеспечивает ли GIT такую ​​же защиту (я где-то читал о опции rebase, которая может быть очень опасной)

Ответы [ 3 ]

13 голосов
/ 30 апреля 2011

Оба являются DVCS, что означает, что вы должны клонировать репозиторий и отправлять свои изменения куда-нибудь, когда вам нужна резервная копия. Если вы делаете это усердно, то неважно, какие разрушительные инструменты вам доступны, поскольку резервные копии дешевы и просты в обслуживании.

Теперь, будьте осторожны, я на 100% предвзятый фанат Git.

Из коробки Mercurial отправляет только одну деструктивную команду - откат. Все остальное относится к расширениям, которые должны быть включены вручную - раздевание, перебазирование и т. Д. Эти расширения, безусловно, разрушительны, поскольку переписывают историю на месте , или уничтожают ее. Чтобы избежать их использования, большинство пользователей Mercurial предпочитают использовать расширение Mercurial Queues, которое позволяет вам поддерживать наборы изменений в качестве гибких патчей, прежде чем устанавливать их в камне как коммиты. По сути это составляет целую VCS, которая находится на вершине Mercurial. Он выполняет свою работу, но должен быть сознательно применен до того, как коммиты будут написаны.

В отличие от этого, Git поставляется с несколькими командами, которые можно считать «деструктивными», но с одним существенным отличием - ничто в базе данных Git не переписано когда-либо . Каждый раз, когда вы используете команды rebase, filter-branch или reset, в базе данных создаются объекты new , а затем указатель ветви обновляется, чтобы указывать на них. Каждый раз, когда указатель ветки обновляется, запись добавляется в его reflog, журнал истории, который находится поверх Git и защищает ваши указатели веток от нежелательных обновлений; всегда можно отменить «деструктивную» команду. Фактически может быть трудно окончательно удалить объект из базы данных Git - для этого необходимо удалить запись reflog и затем удалить незанятые объекты.

Короче говоря:

  • Mercurial по умолчанию безопасен, но добавление бензопилы может полностью его сломать.
  • Git построен из цепных пил с нуля, увеличивая кажущуюся опасность, но есть и безопасность.

Для вашего случая использования преподавания эти различия, как правило, вообще не имеют значения - вы будете обучать основным командам, и если кто-то хочет изучить, единственный способ научиться - это отрубить руку. Говорят, что Mercurial легче для начинающих учиться, но я чувствую, что это в основном потому, что он не раскрывает индекс и поэтому больше похож на Subversion. Полные неофиты для контроля версий могут не извлечь выгоду из этого сходства.

9 голосов
/ 30 апреля 2011

Я не думаю, что 'playskool' - хороший термин для описания Mercurial.Это крупный полнофункциональный DVCS, используемый Python, OpenOffice, Netbeans и многими другими проектами .«Playskool» подразумевает, что он не готов к использованию на производственном уровне или что это разбавленная версия чего-то другого.Оба не соответствуют действительности.Старайтесь не путать юзабилити с простотой или незначительностью.

Некоторые участники отметили, что по умолчанию Hg не поставляется с установленными расширениями, но поскольку расширения очень просты в установке, возможно, стоит знать, какие из них могут вызватьнекоторый "ущерб".Конечно, даже если причинен ущерб, распределенная природа Hg позволит вам удалить поврежденные наборы изменений и повторно вытащить с централизованного сервера (что-то вроде отрезания и повторного увеличения конечности, когда вы об этом думаете).

Я бы также различал Повреждения (повреждение хранилища или потеря данных) и Опасность (ловушка HG или неразумное действие - без потери данных).

Перебазировка

Урон: Использование перебазирования может привести к серьезным конфликтам слияния, если вы пытаетесь перебазировать с revA на revB, и они значительно отличаются.В этих случаях Mercurial создаст файлы .diff, которые позволят вам самостоятельно обработать неудачные слияния.В этом случае объединение может быть сложным и данные могут быть потеряны.

Опасность: rebase изменяет хэш-идентификатор каждого перемещаемого набора изменений, что означает, что его не следует использовать после того, как набор изменений имееттолкнулКроме того, rebase будет применять наборы изменений к ветви по умолчанию, если вы не укажете иное с помощью --keep-branches

Histedit

Урон: Хотя mq, вероятно, являетсяЛучшее расширение, Histedit все еще может быть использован для изменения, изменения или иного редактирования существующих наборов изменений.Использование edit позволяет любому пользователю изменять ревизию, включая отмену всех изменений.Использование drop позволяет полностью удалить наборы изменений.Обе эти операции могут привести к потере данных.

Опасность: Подобно перебазированию, histedit может изменить хэш-идентификатор набора изменений.

Mercurial queues (mq)

Урон: Mq - очень мощная и многогранная функция, поэтому урон, который может быть ей вызванразнообразен.mq strip является простым примером потенциальной потери данных.

Опасность: снова , вызывает изменение идентификатора.

откат

Как вы упомянули, эта операция может привести к некоторому повреждению.Текст справки лучше всего говорит:

Эту команду следует использовать с осторожностью.Существует только один уровень отката, и нет способа отменить откат.Он также восстановит состояние dirstate во время последней транзакции, потеряв при этом все изменения dirstate.

Решение?

Создание безопасного клона перед использованием любого из этих параметров должнопозволит вам преодолеть даже катастрофические повреждения.Положитесь на тот факт, что Hg является DVCS, чтобы всегда иметь копию репозитория, прежде чем пытаться что-нибудь сумасшедшее!

6 голосов
/ 30 апреля 2011

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

Однако, используя команды, все сводится к тому, какие расширения вы включаете в Mercurial. Например, strip довольно «опасно» и включается всякий раз, когда вы решаете использовать расширение mq.

С технической точки зрения Git и hg по умолчанию не изменяют данные, которые были записаны в прошлом. hg всегда только добавляет данные в файлы, а Git имеет свое внутреннее представление данных, которое сохраняется в файлах, которые не меняются после записи.

...