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

Очистка репозитория Mercurial с сохранением истории Kiln / Fogbugz

Версия TL; DR: можно ли реорганизовать репозиторий Mercurial без нарушения истории Kiln / Fogbuz? Или мне нужно начинать заново?

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

Рассматриваемый репозиторий управляется в Mercurial, а удаленный репозиторий размещен в Kiln. Проблемы отслеживаются в Fogbugz. Благодаря некоторым правилам обработки ссылок фиксации, любые ссылки в сообщении фиксации на номер проблемы (дела), например Case 123, преобразуются в ссылки на рассматриваемый случай Fogbugz. В свою очередь, к случаю, который был упомянут, добавлено примечание с сообщением фиксации.

Текущая структура

В настоящее время файловая структура проекта выглядит примерно так:

- /
    +- includes/
    |   +- functions-related-to-abc.php
    |   +- functions-related-to-xyz.php
    |   +- class-something.php
    |   +- classes-several-things.php
    |   +- random-file.php
    |   ...
    |
    +- development/
    |   +- a-plugin-folder/
    |   |   +- some-file.php
    |   |   +- file-with-sensitive-and-non-sensitive-info.php
    |   |   ...
    |   |
    |   +- some-backend-functions-related-to-coding.php
    |   ...
    |
    +- index.php
    +- test-config-file.php
    ...

Целевая структура

Структура, которую я хочу, выглядит примерно так:

- /
    +- build/
    +- doc/
    +- src/
    |   +- functions/
    |   |   +- abc.php  // renamed from includes/functions-related-to-abc.php
    |   |   +- xyz.php  // renamed from includes/functions-related-to-xyz.php
    |   |   ...
    |   |
    |   +- classes/
    |   |   +- something.php       // renamed from includes/class-something.php
    |   |   +- several-things.php  // renamed from includes/classes-several-things.php
    |   |   ...
    |   |
    |   +- view/
    |   |   +- random-file.php  // formerly includes/random-file.php
    |   ...
    |
    |   +- development/
    |   |   +- some-backend-functions-related-to-coding.php
    |   |   ...
    |   +- index.php
    |   ...
    |
    +- test/
    ...

a-plugin-folder переместится в свой отдельный репозиторий. test-config-file.php больше не будет отслеживаться в репозитории. В идеале я также сделаю небольшую обрезку и переименую ветки, пока я нахожусь в этом.

В мире моей мечты file-with-sensitive-and-non-sensitive-info.php каким-то образом отслеживался бы постоянно, но с конфиденциальной информацией (парой паролей), выдернутой в файл конфигурации, который не находится под контролем версий. Я понимаю, что это, вероятно, принятие желаемого за действительное.

Мое текущее мышление

В настоящее время я считаю, что мой список желаний в принципе невозможен: я могу создавать новые, правильно структурированные репозитории с этого момента, но не могу сохранить свою историю изменений, а также внести радикальные структурные изменения, которые мне нужно внести. В этом представлении я должен взять текущую базу кода, реорганизовать ее так, как я хочу, и зафиксировать ее как набор изменений 1 для двух новых репозиториев (корневой репозиторий и репозиторий плагинов). Тогда я бы просто сохранил копию старого репозитория где-нибудь для справки. Основные недостатки: (1) я теряю всю свою историю и (2) перекрестные ссылки Kiln и Fogbugz для исторических коммитов - это тост.

Мой вопрос

Итак, вот вопрос: есть ли способ сделать то, что я хочу - реструктурировать, вытащить несколько файлов и привести все в порядок, не теряя при этом всю свою историю?

Я рассмотрел возможность использования расширения hg convert, интенсивно используя параметры filemap, splicemap и branchmap . Проблемы, которые я вижу с этим подходом, включают: (1) нарушение всех предыдущих сборок, (2) полное отсутствие file-with-sensitive-and-non-sensitive-info.php в предыдущих сборках (или оставление его внутри, что противоречит сути) и (3) рендеринг многих сообщений фиксации дико неверны в той степени, в которой они относятся к именам файлов или структуре репо. Другими словами, я не уверен, что этот вариант принесет мне большую пользу, чем просто запуск чистых, правильно структурированных репозиториев.

Я также рассмотрел крайний вариант: написать своего рода собственный сценарий для создания нового репозитория, просматривая каждую существующую фиксацию, удаляя конфиденциальную информацию из file-with-sensitive-and-non-sensitive-info.php, переписывая сообщения фиксации в необходимом объеме и фиксируя исправленную версию всего. Теоретически это могло бы решить все мои проблемы, но ценой изобретения велосипеда и, вероятно, занимало бы смехотворное количество времени. Я ищу что-то, что не эквивалентно написанию всего hg расширения.

РЕДАКТИРОВАТЬ: Я подумываю о создании пустого репозитория, а затем написании сценария, который использует hg export и hg import для переноса наборов изменений по одному, внося изменения там, где это необходимо, для удаления конфиденциальной информации, такой как пароли, из файлов. Есть ли причина, по которой это не сработает?

repository mercurial fogbugz mercurial-convert kiln
22.02.2014

Ответы:


1

Изменить: я выбрал подход, отличный от описанного ниже. Другой мой ответ объясняет, чем я закончил. Тем не менее, меня все еще очень интересует плагин, подобный описанному ниже, поэтому я оставляю этот пост для справки, если у меня будет время сделать это или кто-то еще захочет взяться за проект.

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

Алгоритм

Краткая версия алгоритма выглядит так:

  1. Создать новый репозиторий

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

    1. Export a changeset from the old repository
    2. Импортируйте набор изменений в новый репозиторий, не фиксируя его.
    3. Внесите необходимые изменения в сообщение фиксации и / или конфиденциальные файлы.
    4. Зафиксируйте набор изменений в новом репозитории, сохранив (возможно, измененное) сообщение фиксации и другие метаданные

  3. Поменяйте местами старый и новый репозитории

Предостережения:

  • Очевидно, что, как и все изменения истории, это работает только для закрытых репозиториев, которые не были извлечены третьими сторонами.
  • Шаг 2 можно и нужно полностью автоматизировать для пакетной обработки ревизий без необходимости редактирования.
  • При необходимости изменений будет необходимо останавливать выполнение.

Заставляя это работать

У меня есть очень простое доказательство концепции пакетного файла, которое доказывает, что это может работать.

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

22.03.2014

2

Я смог достичь своих целей. Вот что я в итоге сделал:

  • Во-первых, я «выровнял» (выпрямил) репозиторий, устранив все ветки и слияния и превратив репо в одну строку коммитов. Мне пришлось это сделать, потому что hg histedit - ключ ко всей очистке - не работает с историей, содержащей слияния. Меня это устраивало, потому что в этом конкретном репозитории не было действительно значимых ветвей или слияний, а в соответствующей истории есть только один автор. Я, вероятно, мог бы сохранить ветви и снова объединить их, если потребуется, позже, но это было проще для моих целей. Для этого я использовал hg rebase и расширение MQ. (Особая благодарность @tghw за этот чрезвычайно полезный ответ, который помог мне впервые понять, как на самом деле работает MQ.)

  • Затем я использовал hg convert для создания нескольких репозиториев из исходного репозитория - по одному для каждой библиотеки / плагина, которые мне нужно было поместить в свой собственный репозиторий, и один основной репозиторий для остальной части кода. В процессе я использовал --filemap и --branchmap, чтобы реорганизовать все по мере необходимости.

  • В-третьих, я использовал hg histedit в каждом новом репозитории, чтобы (1) при необходимости очистить нерелевантные сообщения о фиксации и (2) удалить конфиденциальную информацию.

  • В-четвертых, я отправил все новые репозитории в Kiln, который автоматически связал их с кейсами FogBugz, используя те же правила, что и для исходного репозитория (например, Case 123 в сообщении фиксации создает ссылку на кейс № 123 FogBugz).

  • Наконец, я «удалил» исходный репозиторий в Kiln. Kiln на данный момент не удаляет репозитории полностью и навсегда, хотя я предложил вариант использования, чтобы сделать это возможным. Вместо этого он отсоединяет случаи FogBugz и помещает «удаленный» репозиторий в холодное хранилище; администратор учетной записи может восстановить его, но в остальном он невидим.

В целом, чтобы разбить исходный репозиторий на 6 частей и очистить каждую его часть, потребовалось около 10 часов. Кое-что из этого требовало обучения; Я, вероятно, смог бы проделать все это примерно за 6 часов, если бы мне пришлось повторить это снова. Долгий день, но он того стоит из-за кардинально улучшенной структуры репозитория и очищенного кода.

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

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