Сервер основы команды - движущийся источник с историей

Перемещение и переименование являются псевдонимами. В любой версии TFS нет абсолютно никаких отличий от командной строки или пользовательского интерфейса.

Оба они хранят историю. По крайней мере, в 2005/2008 гг. Вы сохраняете один и тот же физический элемент в таблице VersionedItem независимо от того, как часто и насколько сильно изменяется имя и / или родительский путь. На самом деле нет способа получить "фальшивое" переименование (удаление + добавление) без большой ручной работы с вашей стороны.

Однако, хотя эта модель управления версиями очень чиста в теоретическом смысле, в ней есть некоторые практические ошибки. Поскольку разные элементы могут занимать одно и то же имя в разные моменты времени, TFS требуется полное имя + версия, чтобы однозначно идентифицировать любые входные данные, которые вы ему отправляете. Обычно вы не замечаете этого ограничения, но после переименования элементов в системе, если вы скажете tf [doSomething] $ / newname -version: oldversion , тогда он запутается и либо выдаст ошибку, либо работать с предметом, который вы, возможно, не планировали. Вы должны быть осторожны, передавая допустимые комбинации (новое имя + новая версия или старое имя + старая версия), чтобы команды вели себя так, как вы хотите.

TFS 2010 несколько меняет ситуацию: это ветвь + удаление под крышками, в результате чего изменяется itemID.Тем не менее, такие повседневные команды, как Get и History, очень хорошо «подделываются»; старые клиенты примерно на 95% совместимы. Преимущество состоит в том, что когда у вас есть несколько переименований в системе и поиск элементов на основе пути начинает становиться неоднозначным, как упоминалось выше, сервер просто принимает указанное вами имя и запускается с ним. Это улучшает общую производительность системы и устраняет несколько ловушек, в которые часто попадали незнакомые пользователи, за счет того, что они не так гибки и не сохраняют историю со 100% точностью (например, при конфликте имен во время слияния двух ветвей).

Возвращаясь к проблеме ...

Это не так просто, как сказать tf rename $ / projectA $ / projectB . Папки верхнего уровня в дереве системы управления версиями зарезервированы для мастера создания командных проектов; вы не можете запускать против них стандартные команды tf. Что вам нужно, так это сценарий вроде:

Get-TfsChildItem $/ProjectA |
    select -Skip 1 |  # skip the root dir
    foreach {
        tf rename $_.serveritem $_.serveritem.replace("$/ProjectA", "$/ProjectB")
    }

[конечно, вы можете сделать это вручную, если есть 'слишком много детей под $ / ProjectA]

Что касается ошибок, о которых я упомянул, я остановлюсь на одной прямо сейчас, поскольку поиск старой истории кажется вам очень важным. После того, как вы отметите переименование, tf history $ / ProjectA / somefile.cs НЕ будет работать. По умолчанию команды tf предполагают version = "latest". Любая из этих альтернатив будет иметь полную историю, которую вы хотите:

• tf history $ / ProjectA / somefile.cs; 1234 где набор изменений 1234 был до перемещения
• tf history $ / ProjectB / somefile.cs; 5678 , где набор изменений 5678 был после перемещения. Или вы можете просто опустить версию.

Последняя альтернатива для полноты и целей отладки:

• tf history $ / ProjectA / somefile.cs -slotmode . Вы увидите только те изменения, которые произошли до переезда; однако вы также увидите историю любых других элементов, которые могли существовать в файле $ / ProjectA / somefile.cs «слот» до или после элемента, который вы переместили под B.

(В TFS 2010 «режим слота» является поведением по умолчанию; есть опция -ItemMode, чтобы запросить отслеживание вашего поиска в истории, как это было 2008, а не на основе пути.)

РЕДАКТИРОВАТЬ - нет, ветвление - не лучшая альтернатива. Хотя ветвление действительно оставляет в системе достаточно метаданных для отслеживания полной истории в ProjectB и из него, в 2008 году он не очень удобен для пользователя. Планируйте потратить много времени на изучение команды tf merges (без эквивалента в интерфейсе пользователя) . 2010 значительно улучшает вашу способность визуализировать изменения в нескольких ветвях, но это все еще не тот чистый унифицированный опыт, который вы получили бы от Rename.