Обработка переименовывает: svn по сравнению с мерзавцем по сравнению с подвижным

Вы не ослышались, вроде того.

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

Попробуйте: переименуйте файл, затем запустите 'git rm oldname' и 'git add newname', чтобы сообщить git, что нужно выполнить изменения, затем запустите 'git status', чтобы узнать, что git думает, что он делает - вы увидите, что он сообщает вам, что файл был переименован. Хотя я не уверен, что это значит что-нибудь потом. Посмотрите на фиксацию с помощью 'git show', и вы не увидите никакого упоминания о переименовании, просто набор строк, удаленных из одного пути и добавленных в другой.

В качестве альтернативы, вы также можете использовать команду git mv для переименования файла. Это не меняет того, как git видит операцию, он просто эффективно выполняет 'mv oldname newname', 'git rm oldname' и 'git add newname' за один шаг.

Для обзора Mercurial см. ответ tonfa .

SVN, с другой стороны, не может обнаружить переименования, но о них нужно сообщить с помощью команды 'svn mv'. Однако, когда ему говорят, он отслеживает переименования как «первоклассные» изменения, поэтому при просмотре журнала изменений позже вы увидите, что изменение было переименованием.

Я бы не предлагал выбирать SVN вместо git или mercurial на основе этого особенность, тем не менее. Между инструментами есть гораздо большие и более важные различия. Я'

git отслеживает содержимое, а не файлы. я не уверен насчет Mercurial, но svn нужно явно сообщить о переименовании

Git

Git отличается тем, что не выполняет отслеживание переименования , что означает, что он не выполняет ' О переименовании нужно сообщать с помощью команд SCM для переименования (или запуска сценария автообнаружения для пометки переименований перед фиксацией), и не сохраняет такую ​​информацию в репозитории, но делает обнаружение переименования . Это означает, что он находит переименования с использованием эвристического алгоритма, основанного на сходстве файлов и файлов, как во время слияния, так и для сравнения, когда запрашивается с помощью параметра -M (или настраивается с помощью параметра конфигурации diff.renames

Преимущества этого метода следующие:

• переименования не нужно явно отмечать (или обнаруживать): переименование может происходить из патча или может быть выполнено через файловый менеджер или графический интерфейс
• ] алгоритм обнаружения сходства может быть улучшен и не замораживается во время фиксации, как в случае обнаружения переименований, чтобы пометить их перед фиксацией, и сохранение этой информации в репозитории; также легче иметь дело с ошибками обнаружения переименования, если они не заморожены в истории
• , согласно философии Git, значение имеет содержание; посмотрите, как git blame (и графические интерфейсы к нему, такие как «git gui blame») могут отслеживать перемещение блоков кода через границы файла, что является более общим, чем полное переименование файлов .
• тот же механизм отвечает за обработку переименований во время слияния; использование обнаружения переименования означает, что это можно сделать для 3 коммитов, на которых в конечном итоге основано слияние, и нет необходимости внимательно следить за историей, отмечая каждое переименование - или нераспределенную концепцию канонического имени файла

. фильтрация pathspec плохо работает с обнаружением переименования;

Еще одна вещь о git, которая еще не упоминалась, помимо использования эвристики для определения того, произошло ли переименование:

Если файл или даже все дерево каталогов переименовывается, копируется или перемещается, и ничто внизу не изменяется каким-либо образом, тогда файл или дерево фактически сохраняется как тот же объект внутри репозитория и не занимает никаких дополнительное пространство.

Если вы измените его, он будет сохранен как новый объект, как обычно.

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

На практике:

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

С Mercurial , вы должны явно указать это о переименовании, либо с помощью hg mv , либо с помощью параметра - подобие в hg addremove , либо с помощью параметра TortoiseHg "предположить переименование" , или определенные инструменты, например VisualHg отметит переименование за вас. Если вы хотите использовать подход Git с Mercurial, я написал расширение для обнаружения переименований во время фиксации , но на данный момент оно находится на очень экспериментальной стадии.

Subversion вообще не обрабатывает переименования . Он записывает переименование, когда один файл удаляется, а другой добавляется. Это означает, например, что если Алиса изменяет файл, а Боб переименовывает его, возникает конфликт дерева. Это происходит независимо от того, выполняете ли вы полномасштабное ветвление и слияние или просто svn update . Отслеживание переименования запланировано в Subversion 1.8, которое должно выйти когда-нибудь в следующем году.