Nano Hash - криптовалюты, майнинг, программирование

Синхронизировать 2 ртутных репозитория

Скажем, у нас есть следующая настройка разработки:

  • Команда 1 в местоположении A с центральным ртутным репозиторием, в котором работают все эти команды, подталкивается
  • Команда 2 в местоположении B (на полпути вокруг света от команды 1 и с нестабильным подключением к Интернету) с собственным центральным ртутным репозиторием, где все эти команды работают

Как я могу безопасно синхронизировать центральные репозитории из команды 1 и 2, не сталкиваясь с проблемами слияния / нескольких головок и т. Д.?

Я бы предположил, что запланированное push / pull из одного из репозиториев (например, в местоположении A) в / из другого справится с этим, но как мне справиться с ситуациями, когда задействовано несколько голов?

Например: команда 1 отправляет фиксацию, в то же время команда 2 также отправляет. Теперь, когда репо в местоположении A извлекает изменения, оно получает несколько голов. Что мне теперь делать? Может ли решение здесь заключаться в том, чтобы позволить разработчику из команды 1 (в местоположении A) объединить головы и отправить их обратно в свое центральное репо, чтобы следующий запланированный push в местоположение B подтолкнул слияние? Это привело бы к проблемам, если бы команда 2 уже поместила другие изменения в свой центральный репозиторий, верно?

Есть ли другое решение этой проблемы?

Чего я хочу избежать, так это того, что команде 2 приходится ждать стабилизации подключения к Интернету, чтобы вернуть свои изменения команде 1 ...

Буду рад любой помощи здесь ;-)

repository mercurial
12.10.2011

Ответы:


1

Основное правило - никогда не помещать новые головы в удаленный репозиторий. Потому что, если вы сделаете это, вы создадите головы, которые внезапно появятся в репозитории другой команды, и им придется объединить их, и это сбивает с толку. Mercurial будет жаловаться на это, если вы попытаетесь это сделать, если вы не укажете параметр --force.

Но в остальном это довольно стандартный тариф; вы назначаете одного или нескольких человек, ответственных за слияние двух репозиториев (ежедневно или около того), затем извлекаете все изменения из обеих веток, объединяете две головы, а затем отправляете результат обратно в оба репозитория, как это должен сделать любой член команды . Если что-то выталкивается во время слияния, вам нужно выполнить еще одно слияние (надеюсь, без конфликтов), прежде чем нажимать.

Чтобы частично автоматизировать это, вы можете настроить перехватчик post-push на двух серверах репозитория группы, который асинхронно отправляет изменения на другой сервер и отправляет электронное письмо лицу, ответственному за слияние, в случае сбоя, потому что это создаст удаленные головы. Поскольку временное окно, в котором серверы не синхронизированы, не очень велико, в большинстве случаев это, вероятно, будет успешным. Он должен включать некоторую логику, чтобы не нажимать, если он уже отправляется, и повторять попытку позже, если соединение разорвано.

12.10.2011

2

Если обе команды работают над общей кодовой базой (т.е. один предок существует в репо), я не вижу (кроме обязательного слияния голов из анонимных ветвей) каких-либо проблем в процессе синхронизации - это один из стандартных рабочих процессов ветвления «Ветвление с клоном»

I.e

  • SyncMaster от Team2 создает собственное репо с двумя URL-адресами в разделе [paths] hgrc: RepoTeam1 и RepoTeam2
  • Он тянет из обоих репозиториев, объединяет головы (R2 с R1) из всех существующих веток (если они есть)
  • отправить результаты слияния на R1 и R2

Разделение на уровне веток между репо может помочь слиянию упростить его работу

12.10.2011
  • Tnx @ mikezx6r за исправления моего слишком быстрого набора текста и исправления моих опечаток 12.10.2011

    • 3

    Что ж, толкание и тяга никогда не страдают от конфликтов слияния. Таким образом, обе команды могут работать самостоятельно. В конце концов, кто-то должен вытащить несколько голов из своего центрального местоположения в свое собственное хранилище и объединить головы.

    12.10.2011
  • Я ожидал этого ;-) Так что проталкивание и вытягивание ветки по умолчанию между центральными репозиториями с несколькими головками не должно быть проблемой, верно? 12.10.2011
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..