Есть ли способ исправить неверную дату в истории (будущее), которая искажает отображение истории?

Question

Около 10 лет назад, когда мой коллега только начинал свой проект с использованием Paratext и системы контроля версий Mercurial (Send/Receive), на его компьютере произошли странные вещи с датой. Даты примерно 10 коммитов отображаются в Paratext как 2038, но в других программах Mercurial они показываются как 2095. Хотя номер ревизии ниже, похоже, Paratext отображает историю, сортируя её по дате, и в данном случае это очень раздражает. Изменение даты старого коммита в опубликованном репозитории, кажется, невозможно. Так есть ли у нас какие-либо решения, будь то внутри Paratext, с помощью TortoiseHg или любым другим способом, чтобы избавиться от этих бесполезных коммитов? Они настолько старые, что не добавляют ничего нового, но я не могу, похоже, от них избавиться.

image403×626 130 KB

image618×784 65 KB

Решение, похоже, сводится к одному из следующих вариантов:

1. Удалить всю историю (нежелательно, но легко выполнимо)
2. Paratext изменит порядок сортировки в меню истории, чтобы он основывался на номере ревизии, а не на дате (не стоит делать это только ради одного проекта)
3. Какая-то магия с hg для изменения (опубликованных) коммитов, будь то с использованием rebase, collapse, evolve, histedit или чего-то подобного.

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

1. Мне кажется, что списки истории в Paratext (особенно сравнение текстов) бесполезны и потенциально опасны, если они отсортированы по дате, учитывая возможность того, что даты на компьютере могут быть искажены. Базовая система Mercurial имеет способ упорядочивать ревизии независимо от даты коммита. MacHg и TortoiseHg оба отображают ревизии в правильном порядке, при этом также показывая
2. Текущий интерфейс для перечисления книг с длинной историей изменений становится довольно громоздким и, возможно, может быть сделан более полезным для отслеживания изменений.

Так есть ли какие-либо советы о том, как я могу помочь исправить проект моего коллеги? Кто-нибудь еще считает, что запрос на функцию Paratext для корректировки порядка сортировки отображения истории может быть оправдан?

Переведено машиной с языка English Показать оригинал

Answer 1

rowbory:

3. Какая-то магия с hg для изменения (опубликованных) коммитов, будь то с использованием rebase, collapse, evolve, histedit или чего-то подобного.

Изменение истории имеет смысл только для черновых наборов изменений. Поэтому, если только вы не можете убедить администратора S/R в Paratext внести изменения за вас на сервере S/R и не можете скоординировать действия со всеми пользователями проекта, чтобы они удалили свои копии, а затем обменялись чистой копией, это не совсем безопасный вариант.

Другим вариантом может быть запрос на функцию:
4. Улучшение инструмента администратора Paratext «Convert Project» для автоматического исправления недействительных дат.

Переведено машиной с языка English Показать оригинал

Comments

ИМХО, это достаточно уникальная ситуация, с которой следует иметь дело внешними средствами, и не стоит перепрограммировать PT. Просто мое мнение.

На основе моих собственных экспериментов с Mercurial, мое предположение состоит в том, что вы можете сделать rebase или иным образом отредактировать историю в Mercurial, но, вероятно, это приведет к пересчету всех хэшей для коммитов. По сути, вы разветвляете проект. Это потребует удаления проекта из Registry и с компьютера каждого участника, а затем повторного обмена им.

Переведено машиной с языка English Показать оригинал

---

Спасибо. Хорошо, что есть подтверждение. По сути, то, что я надеялся сделать как простое исправление, оказывается нетривиальной проблемой. Просто неудачно, что Paratext, в отличие от клиентов Mercurial, сортирует по дате коммита, а не по идентификатору ревизии.

Переведено машиной с языка English Показать оригинал

---

Одно из соображений: порядок наборов изменений (идентификаторы ревизий) может быть разным для разных пользователей. (Использование даты, по крайней мере, делает вещи последовательными для каждого пользователя). Также, если у вас есть пользователь, который редко выполняет S/R, то изменения, которые он внес несколько месяцев назад, могут отображаться перед изменениями, которые другой пользователь сделал вчера. (если сортировка по идентификатору ревизии)

Переведено машиной с языка English Показать оригинал