Ртутная ошибка: хранилище не связано - PullRequest
Новая
       23

Ртутная ошибка: хранилище не связано

33 голосов
/ 06 сентября 2011

Я только начал работать с Mercurial, у меня есть «центральный» репозиторий в Bitbucket, который я клонировал на одну машину, вносил изменения, фиксировал и выдвигал. Затем я клонировал из Bitbucket на другой совершенный компьютер и нажал, что было хорошо. Затем я вернулся к первой машине, внес изменения и попытался нажать, но получил сообщение об ошибке. Что я делаю неправильно? Я должен был вытащить первым? Как я могу устранить ошибку и нажать? Любая помощь приветствуется!

Даррен.

Ответы [ 4 ]

37 голосов
/ 06 сентября 2011

Репозиторий Mercurial получает свою идентичность, когда вы делаете первый коммит в нем.Когда вы создаете новый репозиторий в Bitbucket, вы создаете пустой репозиторий без идентификатора.

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

Пожалуйста, запустите hg paths на машине, где вы не можетеОт себя.Затем создайте отдельный клон репозитория, в котором будет указано, что он будет выдвигаться.Теперь проверьте первый набор изменений в каждом репозитории с помощью 

hg log -r 0

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

3 голосов
/ 23 октября 2015

Я хотел бы поделиться знаниями о внутренних органах Mercurial.

Хранилища не связаны, если они не имеют одинаковых ревизий.

Соответствующий предмет вы можете найти в mercurial/treediscovery.py: 

base = list(base)
if base == [nullid]:
    if force:
        repo.ui.warn(_("warning: repository is unrelated\n"))
    else:
        raise util.Abort(_("repository is unrelated"))

base - список корней общих частей в локальных / удаленных репозиториях.

Вы всегда можете знать, чем отличаются репозитории: 

$ hg in $REMOTE
$ hg out $REMOTE

Вы всегда можете проверять корни обоих (после локального клонирования): 

$ hg -R $ONE log -r "roots(all())"
$ hg -R $TWO log -r "roots(all())"

если выходные команды, указанные выше, не имеют идентификаторов - эти репозитории не связаны. Из-за свойств hash очень невозможно, чтобы корни случайно были равны. Вы не можете обманывать проверку корней, тщательно создавая хранилища, потому что построение двух хранилищ выглядит следующим образом (с общими частями, но разными корнями): 

0 <--- SHA-256-XXX <--- SHA-256-YYY <--- SHA-256-ZZZ
0 <--- SHA-256-YYY <--- SHA-256-ZZZ

невозможно, потому что это означает, что вы обращаетесь к SHA-256, поскольку каждый последующий хэш зависит от предыдущих значений.

Имея эту информацию, я полагаю, что любой разработчик сможет устранить неполадки error: repository is unrelated.

См. Также Идентификация ртутного хранилища

Спасибо за внимание, хорошего взлома!

3 голосов
/ 06 сентября 2011

Если вы абсолютно уверены, что путь принудительной отправки верен, возможно, стоит просто экспортировать изменения в патчи из репозитория проблемы, снова клонировать из Bitbucket, а затем импортировать патчи в новое репо.Это либо сработает, либо покажет плохой / испорченный коммит.

0 голосов
/ 06 сентября 2011

Вы получаете это сообщение, когда пытаетесь отправить в хранилище, отличное от того, которое вы клонировали. Дважды проверьте адрес нажатия или путь default, если вы просто используете hg push.

Чтобы проверить путь по умолчанию, вы можете использовать hg showconfig | grep ^paths\.default (или просто hg showconfig и искать строку, которая начинается paths.default=).

...