Существует ли современная бесплатная D? VCS, которая может игнорировать порядковые номера мэйнфреймов?

Question

Я смотрю на миграцию большого набора программ IBM Assembler Language, от vcs, основанного на «именах файлов, включающих номера версий», до современного vcs, который даст мне, среди прочего, возможность ветвиться и объединяться.

Эти файлы содержат записи из 80 столбцов, причем последние 8 столбцов представляют собой почти бессмысленный порядковый номер.

По ряду причин, по которым я не хочу тратить впустую пространство, мне нужно, чтобы vcs игнорировал (но, надеюсь, сохранил каким-то четко определенным образом) столбцы порядкового номера, а также использовал diff и patch только на содержание первых 72 столбцов.

Есть идеи?

---

Просто чтобы уточнить "игнорировать, но сохранить": я согласен, что это немного расплывчато, поскольку я еще не полностью собрал свои идеи.

Было бы что-то вроде этого:

"При объединении / исправлении, если у одной стороны есть порядковые номера, выведите их; если у нескольких сторон есть порядковые номера, используйте те, которые присутствуют в файле (1 | 2 | 3)"

---

Почему я хочу сохранить порядковые номера? Во-первых, они являются порядковыми номерами. Во-вторых, я хочу реинтегрировать этот материал обратно в мэйнфрейм, где порядковые номера могут быть очень значительными. (Те из вас, кто знает, что означает «SMP / E», поймут. Те, кто не знает, будут счастливы, но дрожат ...)

---

Я только что понял, что не принял ответ. Трудный выбор, но @Noldorin подходит ближе всего к тому, куда мне нужно идти.

Answer 1

В Mercurial вы можете легко игнорировать столбцы 73-конца файлов .asm - просто добавьте в ваш .hgrc следующие строки:

[encode]
*.asm: cut -b -72

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

Answer 2

Я считаю, что любая современная система управления версиями ( Subversion и Bazaar - это те, которые я обычно рекомендую, поскольку централизованная и распределенная соответственно) может использовать внешнюю инструмент сравнения / слияния. К сожалению, я думаю, что вам придется написать этот собственный инструмент слияния (по крайней мере, я никогда не слышал о том, который делает то, что вам нужно), хотя это не должно быть огромной задачей, я бы вообразил. Сказав это, вам может повезти с рекомендациями, приведенными в этом вопросе StackOverflow , а также в этом . Извините, я не могу дать больше информации о том, какие из них вы хотите изучить, в частности, но стоит ознакомиться с ними на тот случай, если какой-либо из них действительно соответствует вашим требованиям.

Answer 3

(Раскрытие: я представляю поставщика инструмента, описанного в этом ответе).

Вам нужен инструмент сравнения, который понимает, что содержимое столбцов 72-80 - это «пробел», независимо от того, что вы заполнили его символами.

Семантическая модель COBOL Smart Differencer имеет вариант IBM Enterprise COBOL, который прекрасно это понимает.

SD делает Smart Differencers для множества языков, а IBM Assembler - будущая цель. Если вам интересно, свяжитесь с SD в автономном режиме, чтобы обсудить Smart Differencer для IBM Assembler.

Answer 4

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

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