Помещение проекта управления версиями, но не через источник в систему контроля версий

Question

У меня есть какой-то старый код (старое, но все еще поддерживаемое приложение VB6), который с точки зрения контроля источников является лучшим примером сантехника сантехника (или ботинок сапожника). Это была версия, управляемая подходом создания нового каталога для каждой версии.

Существуют ли какие-либо серьезные недостатки в использовании следующего подхода?

1. Выполнить первоначальную регистрацию всех файлов
2. Удалить все файлы из рабочего каталога, затем скопировать все файлы из следующей версии в рабочий каталог
3. Отметьте их в
4. Перейти к # 2, пока не будет сделано

Обратите внимание, что у меня есть общий текстовый файл журнала изменений, из которого я собирал комментарии для каждой версии, в которой я регистрирую / фиксирую. У меня нет (или я действительно беспокоюсь об этом) комментариев к каждому файлу.

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

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

Answer 1

Есть ли значение в изменениях, внесенных в предыдущие версии?

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

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

Answer 2

Это разумный подход. Некоторые системы контроля версий (например, TFS) будут молча игнорировать попытки проверить файл, который не изменился. Это хорошая вещь. Если у вас нет этой функции, я рекомендую сделать diff для всех файлов и проверить только измененные. В противном случае вы добавляете много шума в историю файлов.