В Mercurial, когда Питер "hg clone" меня, и я фиксирую, а он тянет и обновляет, он получает мою версию, но не когда я откатываюсь?

Question

То есть в Mercurial, если Петр клонировал от меня

hg clone c:\mycode e:\code

в свой e: \ code

допустим, есть файл code.txt, который содержит текст the code is 7

Теперь, когда я изменю его на the code is 11 и hg commit, он сможет получить мой код, используя hg pull и hg update. Теперь его версия гласит the code is 11

Но если я решу, что изменение было неправильным и отката hg, то мой репозиторий должен иметь версию 7, а рабочий каталог должен иметь версию 11.

Поэтому, когда Питер выполняет hg pull и hg update, он должен быть синхронизирован с моим текущим репозиторием, который является 7, но я обнаружил, что это не так - он все еще получает 11 версия. Это почему? Может ли он получить откатный код (7)? Git ведет себя так же?

Обновление: Я думал commit влияет на хранилище точно так же, как rollback влияет на хранилище - commit и rollback - это слова транзакции БД ... и теперь мы говорим commit влияет на хранилище, но rollback нет? Какое здесь правило?

Обновление 2: В этот момент, если Мэри делает

hg clone c:\mycode e:\marycode

на данный момент она фактически получает 7 версию. Итак, Мэри получает 7. Питер получает 11. И они оба "в курсе"? Что это?

Answer 1

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

Если вы делаете новый коммит, имеющий состояние откатазатем этот коммит будет отменен, и Питер увидит его.

Другими словами, вам нужно сначала использовать hg revert -r <previous-rev>, чтобы проверить более раннюю версию, на которую вы хотите вернуться, затемиспользуйте hg commit для создания нового коммита на основе более старой ревизии, а затем попросите людей извлечь этот коммит.

Answer 2

hg pull не полная синхронизация.Все, что делает hg pull remote, - это копирует все изменения в remote, которых нет в локальном репозитории, в локальный репозиторий.Все, что rollback делает, это удаляет самый последний коммит (или, в более общем случае, операцию БД, но это почти всегда коммит) - он не записывает никакого вида сообщения «коммит был удален».Коммит ушел навсегда, если только в другом хранилище его нет.Чтобы записать его реверсирование, чтобы другие репозитории получили реверсирование, вам нужен реверсивный коммит (его можно создать с помощью hg backout).Затем у вас есть еще один коммит, который полностью изменяет эффект предыдущего.

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

В сценарии клонирования они оба актуальны (так как обе содержат ревизию 7), но у Питера естьдополнительная ревизия.Как будто Питер сам создал изменение 11 и подписал на нем свое имя.

rollback нельзя использовать безопасно или осмысленно в кросс-репозитории.Для этого вам нужно backout.По этой причине я всегда предпочитаю нажимать на опубликованные места и заставлять людей извлекать их оттуда, а не заставлять их извлекать данные прямо из моего рабочего хранилища, чтобы я знал, когда rollback безопасно, а когда - нет (в течение нескольких разкогда мне это нужно).

Answer 3

Я не использую Mercurial, но так как вы спросили, как Git ведет себя в этом отношении ...

В Git есть два способа отменить: revert и reset.

Команда revert исправляет существующий код так, чтобы он напоминал предыдущее состояние: в истории будет записано изменение с исходного «кода на 7» на «код на 11», а затем исправление на «код7 ".

С другой стороны, reset - это фактическое" перематывание "истории.Если эта команда используется, изменение в «коде 11» удаляется из дерева истории, и состояние хранилища такое, как если бы изменение никогда не происходило.

Таким образом, тогда как revert и reset может привести к тому, что ваш репозиторий, по-видимому, будет восстановлен в том же состоянии, которое существовало до изменения на «код 11», они концептуально очень разные операции.revert на самом деле создает новую историю, а reset удаляет существующую историю.

На практике, если операция revert выполняется в хранилище, и Питер вытягиваетИсходя из этого, в самом деле, его репозиторий также будет записывать изменение обратно на «код 7».С другой стороны, если операция reset выполняется в хранилище, то из POV репо Питера хранилище, из которого он извлекает, в действительности находится в более старом состоянии, чем его, и ничего не произойдет.Вот почему с Git вы должны использовать reset, только если никто не извлекал ваши изменения (или вы не отправляли на пульт).При любых других обстоятельствах вы должны использовать revert.

Answer 4

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