Если TFS идет от кода, то почему в истории нет колонки, которая позволяет увидеть номера WI?
Ведь это позволяет глядя историю кода открыть соответствующий WI.
TFS заставляет меня найти WI, и в его линках искать изменения в коде.
Это позволяет мне сразу оценить несколько аспектов починки всего бага, а не одного чейнджсета.
Например, какие проекты были затронуты, а есть ли тесты, на что изменения могут повлиять.
На основании этой информации можно принять другие более конкретные решения.
У меня это довольно частый сценарий. И TFS не поддерживает его :(.
Такое чувство, что TFS идет не от кода, а от WI (дефект, задача и т.п.), т.е. он более заточен не для программиста, а не понятно для кого. Поэтому и «продают» его не программистам, а более другим людям.
У меня есть привычный (и очень логичный) сценарий и я ищу как он решается в TFS: так вот он поддерживается очень плохо.
Не нашел способа увидеть список всех изменений «дефекта».
И при этом TFS позиционируется (продается) как ALM.
Цель данного поста показать какие возникнут вопросы у тех, кто переходит с SVN на TFS с надеждой, что более опытные пользователи TFS покажут как им правильно пользоваться.
Еще вы совершенно упускаете My work (хотя он доступен только от Premium и выше).
Согласен. Не знаю что это такое, но теперь попрбую. Спасибо!
Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).
Тривиально: из WI открываете all links, там будут все changeset, которые ассоциировали с этим WI. Дальше по двойному клику на чейнджсете вы получаете полный список всех изменений этого чейнджсета.
Да, я получу список всех изменений этого чейнджсета, но часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).
Термин «Система управления дефектами» понятен и является подмножеством Work Item management. Если хотите улучшить мир, добавьте правильный термин тут и я им буду пользоваться.
Я не нашел способа в TFS увидеть сразу список всех измененных файлов для дефекта. Студия требует перемещаться по каждой привязке (association).
Мне сейчас больше мешает отсутсвие элементарных вещей в плагине для Windows Explorer.
Так что мой ответ "чтобы команда TFS тратила время на доработку PowerTools".
Я думаю, Microsoft может себе позволить успеть и то и другое.
После «пустого» не проверял, только сегодня открыл диалог «Source Control Merge Wizard» и увидел те же самые «старые» ревизии.
Немного проверил: судя по всему «старые» ревизии появились до появление последнего changeset.
Сегодня опять проявились интересные особенности мержа: у нас тут бегает утилика, которая посылает отчет с набором changesets, которые не были замержены между Main двух версий (смотрите код ниже).
Вчера она прислала «пустой» отчет. А после добавления одного changeset, она прислала отчет с 4 не замерженными changesets, причем 3 из которых месячной давности. На всякий случай добавлю, что это происходит не первый раз.
Господа, я все понимаю: новая философия, свои понятия, но как мне сделать то, что в SVN называется Export?
Мне надо просто получить исходники проектика на своем диске без всяких привязок к контролю версий?
Чисто теоритически, если баг в dev был уже пофиксен, то можно было просто «спустить» необходимые изменения (конкретные changeset'ы) из dev в main.
Когда это возможно, то конечно. Но не всегда это можно сделать: если баг починен как часть redesign, то ествественно мы не хотим весь redesign переносить в продакшн версию: правильнее просто починить баг.
Иногда в продакшн делается заплатка, которая не переносится, а проблема решается более общим подходом.
Все таки «версия 1 „- это версия 1 продукта, а “версия 2» — это следующая версия продукта (это не совсем mail и dev).
Если продолжить ваш сценарий, то может быть этот баг уже был починен (или не актуален) в версии 2 (dev — как вы его назвали), в этом случае нет необходимости переносить ветвь (так правильно?) из версии 1 в версию 2.
Хорошо. Буду придерживаться этого определения.
Если заменить все мои использования слова "ревизия" на "changeset" (не знаю как правильно это называется по-русски), то что изменится?
Ведь это позволяет глядя историю кода открыть соответствующий WI.
TFS заставляет меня найти WI, и в его линках искать изменения в коде.
Например, какие проекты были затронуты, а есть ли тесты, на что изменения могут повлиять.
На основании этой информации можно принять другие более конкретные решения.
Такое чувство, что TFS идет не от кода, а от WI (дефект, задача и т.п.), т.е. он более заточен не для программиста, а не понятно для кого. Поэтому и «продают» его не программистам, а более другим людям.
Не нашел способа увидеть список всех изменений «дефекта».
И при этом TFS позиционируется (продается) как ALM.
Цель данного поста показать какие возникнут вопросы у тех, кто переходит с SVN на TFS с надеждой, что более опытные пользователи TFS покажут как им правильно пользоваться.
Согласен. Не знаю что это такое, но теперь попрбую. Спасибо!
Да, я получу список всех изменений этого чейнджсета, но часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).
Я не нашел способа в TFS увидеть сразу список всех измененных файлов для дефекта. Студия требует перемещаться по каждой привязке (association).
Так что мой ответ "чтобы команда TFS тратила время на доработку PowerTools".
Я думаю, Microsoft может себе позволить успеть и то и другое.
Что имеется ввиду под shelveset в SVN?
Так я просто хотел посмотреть код утилитки.
Хотя может пригодиться и для запуска тестов.
ну да. А чего TFS команда так не любит PowerTools?
Немного проверил: судя по всему «старые» ревизии появились до появление последнего changeset.
Вчера она прислала «пустой» отчет. А после добавления одного changeset, она прислала отчет с 4 не замерженными changesets, причем 3 из которых месячной давности. На всякий случай добавлю, что это происходит не первый раз.
Мне надо просто получить исходники проектика на своем диске без всяких привязок к контролю версий?
Когда это возможно, то конечно. Но не всегда это можно сделать: если баг починен как часть redesign, то ествественно мы не хотим весь redesign переносить в продакшн версию: правильнее просто починить баг.
Иногда в продакшн делается заплатка, которая не переносится, а проблема решается более общим подходом.
Еще нет, но линк уже открыл.
Спасибо.
Если продолжить ваш сценарий, то может быть этот баг уже был починен (или не актуален) в версии 2 (dev — как вы его назвали), в этом случае нет необходимости переносить ветвь (так правильно?) из версии 1 в версию 2.
Я тоже стараюсь так людей учить :)
Если заменить все мои использования слова "ревизия" на "changeset" (не знаю как правильно это называется по-русски), то что изменится?