alexander-linkov / file-mover

file-mover

Утилиту надо запускать из корня проекта.

В Source path указывается путь до исходных файлов. Утилита сканирует указанную папку, и заносит все найденные файлы в список Source Files. В поле Target path указывается путь, куда будут переносится файлы. (Если указать такую же папку, как и в Source path, то они будут переименованы). Source Path и Target path указываются относительно рабочей папки (т.е. папки проекта).

Список Target Names изначально дублирует левый список, и обновляется одновременно с ним. Он редактируемый и в нем вы задаете будущие имена файлов. Чтобы не обрабатывать файл, снимите галочку в правом списке. (Select All, Select None и Invert Selection помогут в большом списке).

Списки синхронизированы, поэтому исходные и конечные имена находятся напротив друг друга. При выборе файла в левом или правом списке, в поле снизу покажется превью содержимого. Может помочь понять о чем речь в топике. Для запуска нажимайте Rename\Fix Links. Отменить процесс можно нажав на кнопку Cancel в нижнем правом углу (уже обработанные файлы в исходное состояние не вернутся).

Load From File

Нажав на Load from File можно загрузить соответствующий список файлов из текстового файла. Пока указан файл, все пути считаются от рабочей папки. Таким образом пути в файлах надо писать относительно рабочей папки. Например

old_files.txt:
_topics\basics\ui\panels\keyword-test-editor\about-keyword-test-editor.xml

new_files.txt:
keyword-testing\editor\about.xml

Обе кнопки Load from file работают независимо, поэтому можно загрузить список файлов для переименовывания из файла, а новые имена ввести вручную.

При использовании Git Так как у Git не очень всё прозрачно с указанием переименовывания файлов, я сделал быстро решение, как переносить файлы с сохранением истории. Git определяет rename только если файлы похожи более чем какой-то порог. В обычно процессе переименовывания файлы скорее всего будут изменяться и возможно будут осечки. Чтобы как-то это предотвратить я добавил возможность разбить процесс на два шага.

1. Вначале мы переименовываем, используя галочку Just Rename. Файлы будут просто перенесены, ссылки не проверены. При этом список со старыми и новыми именами сохранится в файл проета с именем исходного каталога (например “_topics-about-copyright-OLD.orig” и “_topics-about-copyright-NEW.orig”). Комитим изменения. Git должен правильно распознать связь файлов и сохранить историю.
2. Загружаем списки файлов используя созданные файлы, отмечаем галочки Just Fix Links и After Rename. Выполняем проверку. Коммитим исправления. В таком режиме Git должен будет сохранить историю изменений даже при очень сильном изменении внутри файла. Теоретически, можно работать по старому, но вероятность обнаружение переименовываний будет ниже. Также можно делать переименовывание средствами Git. Для этого отметьте Use command line for rename. Укажите Git и путь до git.exe. Переименовывание будет немного дольше, потому что каждый раз будет вызываться коммандная строка Git (переименовывать все файлы пачкой я пока не сделал). Замечу, что особых преимуществ от данной опции я не заметил. Разве что Source Tree сразу помечает файлы как Rename (однако если такой файл изменить, то он может перестать понимать сходство).

Fixing Links

При обработке файла, вставляемые ссылки проверяются на достоверность. Есть возможность просто проверить ссылки без переноса файла – для этого выберите Just Fix Links.

Ссылка на *.dtd и *.xsl исправляются автоматически на файлы указанные в полях DTD и XSL. Чтобы проверять ссылки только на эти файлы надо выбрать Only Template Links. Есть возможность не проверять ссылки, содержащие Upper Case (такие ссылки часто встречаются в комментариях и не нужны). Для этого надо выбрать Ignore Upper Case Links. При выборе Just Fix Links, список Target Names становится недоступным и полностью копирует Source Files. Если вам надо проверить ссылки в перенесенных файлах выберите After Rename – это позволит указать новые имена файлов. В этом режиме, если ссылка уже ведет на какой-то файл, она не исправляется, т.к. скорее всего уже была исправлена.

Для принудительной замены полных ссылок на относительные отметить Make All Links Relative.

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

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

Как работает утилита

Используя старый и новый пути утилита:

1. обновит все ссылки внутри файлов (если это был xml);
2. проверит, что новые ссылки ведут на существующие файлы. Если нет, предложит указать правильный путь;
3. скопирует файлы на новое место (если не отмечен режим Just Fix Links);
4. просканирует все xml файлы в папке проекта и найдет все ссылки на файлы и
5. скорректирует их (если отмечен Just Fix Links, но не отмечен After Rename – тогда этот шаг пропускается);
6. переименует старый файл в «old_name.orig» (на всякий случай).

Что она НЕ делает:

• Не переносит файлы используя команды mercurial. Такая возможность появилась для Git. Поддержка Mercurial появится по необходимости.

Особенности:

• После редактирования source path (даже если текст по факту не поменялся) левый список обновится, а, следовательно обновится и правый список. А значит все новые имена, что были заданы в правом списке сотрутся. Имейте это ввиду.
• Чтобы перенести файл в подпапку можно использовать в новом имени обратную косую черту () С простым слешем работать не будет. Например subfolder\new-file.xml создаст в папке Target path, подпапку subforder и поместит туда файл с именем new-file.xml
• Расширение автоматически не проставляется.
• Список файлов игнорирует файлы “.orig”, ".html" и ".htm".
• В полях Source path и Target path последним символом может стоять обратный слеш. Он там не обязателен, но если Вы его там поставили, то проверьте, что он стоит в обоих полях. На всякий случай утилита это проверяет, но я мог, что-то пропустить.
• Файлы переносятся используя средства .NET. Это значит, что надо обязательно воспользоваться функцией Detect Renames в TortoiseHg. Мне такой подход показался удобней, т.к. я использую этот диалог (где видно прошлые и будущие имена уже перенесенных файлов) при редактировании проекта.
• В папке с программой ведется лог (файл file_mover.log). Там отмечаются какие замены были выполнены в каких файлах.
• Для поиска ссылок используется регулярная строка. За время тестирования я нашел более-менее точные выражения, но вероятность ошибки все еще есть. Я переработал механизм определения в переносимом файле, поэтому стало лучше. Но лучше проверять битые ссылки после переноса.