Комментарии 153
1. Это не система управления дефектами. Потрудитесь открыть переводчик и перевести хотя-бы дословно Work Item. Ибо не хочется дальше даже читать, но я прочитал.
2. Я так и не понял, чем вас не устраивает работа в VS с привязкой к рабочим элементам исходного кода, причем можно:
2.1 Просто привязать (association)
2.2 Привязать и совершить событие (resolve task, us и т.д.)
После чего, просматривая WorkItems можно видеть все изменения. Более того, в Builds они тоже уйдут.
2. Я так и не понял, чем вас не устраивает работа в VS с привязкой к рабочим элементам исходного кода, причем можно:
2.1 Просто привязать (association)
2.2 Привязать и совершить событие (resolve task, us и т.д.)
После чего, просматривая WorkItems можно видеть все изменения. Более того, в Builds они тоже уйдут.
Термин «Система управления дефектами» понятен и является подмножеством Work Item management. Если хотите улучшить мир, добавьте правильный термин тут и я им буду пользоваться.
Я не нашел способа в TFS увидеть сразу список всех измененных файлов для дефекта. Студия требует перемещаться по каждой привязке (association).
Я не нашел способа в TFS увидеть сразу список всех измененных файлов для дефекта. Студия требует перемещаться по каждой привязке (association).
НЛО прилетело и опубликовало эту надпись здесь
Немного (или много) раздражает смена инструментов (Power Tools, Studio и web), так нет такого, который работает лучше остальных.
Для всего, что связано с кодом, лучше работает VS. Для планирования — web. Интеграция с Windows Explorer нужна только для edge-case-сценариев, в норме ей лучше не пользоваться.
Студия позволяет добавить номер «дефекта» по запросу и собственно номеру.
Еще вы совершенно упускаете My work (хотя он доступен только от Premium и выше).
Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).
Тривиально: из WI открываете all links, там будут все changeset, которые ассоциировали с этим WI. Дальше по двойному клику на чейнджсете вы получаете полный список всех изменений этого чейнджсета.
My work все же несколько иное. Я так и боюсь начать им пользоваться.
Весь негатив автора вокруг того, что ему не нравится закладка all links, он хочет, чтобы у него все файлы были сразу одним списком, как SVN показывает в хистори.
Я не нахожу ничего лучше, чем привести пример:
— я хочу, чтобы как в KDE
— постойте, мы же в windows
— а я хочу, иначе, ваш продукт выбросить.
Весь негатив автора вокруг того, что ему не нравится закладка all links, он хочет, чтобы у него все файлы были сразу одним списком, как SVN показывает в хистори.
Я не нахожу ничего лучше, чем привести пример:
— я хочу, чтобы как в KDE
— постойте, мы же в windows
— а я хочу, иначе, ваш продукт выбросить.
У меня есть привычный (и очень логичный) сценарий и я ищу как он решается в TFS: так вот он поддерживается очень плохо.
Не нашел способа увидеть список всех изменений «дефекта».
И при этом TFS позиционируется (продается) как ALM.
Цель данного поста показать какие возникнут вопросы у тех, кто переходит с SVN на TFS с надеждой, что более опытные пользователи TFS покажут как им правильно пользоваться.
Не нашел способа увидеть список всех изменений «дефекта».
И при этом TFS позиционируется (продается) как ALM.
Цель данного поста показать какие возникнут вопросы у тех, кто переходит с SVN на TFS с надеждой, что более опытные пользователи TFS покажут как им правильно пользоваться.
Логичность понятие весьма относительно. Я считаю себя достаточно опытным человеком, общающимся с ТФС уже больше 4 лет.
От установки как есть, до настройки и конфигурации под «иные» требования. Но у меня никогда не возникало необходимости искать все файлы, которые прилинкованы к WI. И ранее, за 5 лет с SVN, не возникало. Что я делаю не так?
А по теме: простого и удобного способа, лучше чем из All Links нет. Можно, конечно, написать свой запрос, в TFS все хранится в сиквеле, но стоимость и необходимость этого сомнительна, для меня, лично.
От установки как есть, до настройки и конфигурации под «иные» требования. Но у меня никогда не возникало необходимости искать все файлы, которые прилинкованы к WI. И ранее, за 5 лет с SVN, не возникало. Что я делаю не так?
А по теме: простого и удобного способа, лучше чем из All Links нет. Можно, конечно, написать свой запрос, в TFS все хранится в сиквеле, но стоимость и необходимость этого сомнительна, для меня, лично.
Ну, справедливости ради, мне вот очень не хватает в Version History колонки с номерами задач — у меня часто возникает необходимость понять, кто и зачем что-то чекинил, а делать это отдельно по каждому CS — муторно. Но это весьма специфический сценарий, связанный с аудитом работ в команде.
У меня это довольно частый сценарий. И TFS не поддерживает его :(.
Такое чувство, что TFS идет не от кода, а от WI (дефект, задача и т.п.), т.е. он более заточен не для программиста, а не понятно для кого. Поэтому и «продают» его не программистам, а более другим людям.
Такое чувство, что TFS идет не от кода, а от WI (дефект, задача и т.п.), т.е. он более заточен не для программиста, а не понятно для кого. Поэтому и «продают» его не программистам, а более другим людям.
Вы путаетесь. TFS как раз идет от кода, но «от кода» — это «открыл код — сказал annotate — нажал в номер cs — посмотрел комментарии — нажал в wi — посмотрел описание». А то, что нужно мне — это не «от кода», а журнал аудита.
Если TFS идет от кода, то почему в истории нет колонки, которая позволяет увидеть номера WI?
Ведь это позволяет глядя историю кода открыть соответствующий WI.
TFS заставляет меня найти WI, и в его линках искать изменения в коде.
Ведь это позволяет глядя историю кода открыть соответствующий WI.
TFS заставляет меня найти WI, и в его линках искать изменения в коде.
Ведь это позволяет глядя историю кода открыть соответствующий WI.
Зачем? У меня никогда не возникало такого сценария. У меня есть сценарий «мне надо понять, почему в этом месте кода написано такое», и для этого достаточен Annotate.
TFS заставляет меня найти WI, и в его линках искать изменения в коде.
Если вы, как вы говорите, идете от истории, то достаточно кликать на каждый CS и в его ассоциациях смотреть нужные WI.
едь это позволяет глядя историю кода открыть соответствующий WI.
Зачем? У меня никогда не возникало такого сценария. У меня есть сценарий «мне надо понять, почему в этом месте кода написано такое», и для этого достаточен Annotate.
Оба эти сценария у меня популярны.
Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.
Если вы, как вы говорите, идете от истории, то достаточно кликать на каждый CS и в его ассоциациях смотреть нужные WI.
«достаточно кликать на каждый CS» — в этом то и дело! SVN позволяет не кликать на каждый, а видеть колонку со всеми номерами дефектов, далее фильтровать ревизии по номеру дефекта и видеть все файлы выбранных ревизий. Это сильно экономит время!
Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.
Зачем?
Например:
Открываешь вечером историю, сразу видишь кто что сделал сегодня и быстро понимаешь какие баги чинились, какие файлы менялись. Далее, в зависимости от этой информации, изучаешь более конкретно те или иные ревизии.
Открываешь вечером историю, сразу видишь кто что сделал сегодня и быстро понимаешь какие баги чинились, какие файлы менялись. Далее, в зависимости от этой информации, изучаешь более конкретно те или иные ревизии.
Открываете, читаете комменты и получаете всю ту же информацию.
Важно понять, что по таблице ассоциаций не видно, какие задачи были сделаны, только над какими велась работа.
Важно понять, что по таблице ассоциаций не видно, какие задачи были сделаны, только над какими велась работа.
Важно понять, что по таблице ассоциаций не видно, какие задачи были сделаны, только над какими велась работа.
Согласен. Но прежде всего мне надо оценить в общем состоянии истории, а потом заняться конкретными дефектами или ревизиями.
Комменты рулят. Они намного информативнее номеров задач.
Согласен, а если пометить обязательность постановки и воспитать разработчиков — вообще милость.
Хорошие комментарии конечно же облегчают понимание.
Но все-таки легче «заставить» писать хотя бы номер, чем нормальные комментарии.
Но все-таки легче «заставить» писать хотя бы номер, чем нормальные комментарии.
Для читающего в номере пользы нет никакой, их невозможно держать в голове при постоянном потоке.
Конечно. Поэтому по номеру можно кликнуть и почитать WI.
Не всегда меня интересует, что написано в WI, а более интересно сколько ревизий, есть ли тесты, какие части проекта затронуты.
Не всегда меня интересует, что написано в WI, а более интересно сколько ревизий, есть ли тесты, какие части проекта затронуты.
Это надо делать по каждой задаче отдельно.
А вообще, все, что вам нужно, легко реализуется собственным агентом, благо API у TFS — открытый.
А вообще, все, что вам нужно, легко реализуется собственным агентом, благо API у TFS — открытый.
Почему то никто не написал что-нибудь на уровне TortoiseSVN или я не заметил?
Потому что не нужно.
например, не нужно иметь аннотацию из Windows Explorer?
Почему?
Почему?
Потому что основной инструмент для работы с кодом — это IDE. В основных IDE, на которые рассчитан TFS, аннотация встроена. Писать собственный визуализатор, да еще и с поддержкой всего того, что есть в студии — дорого.
С текущим состояним кода — да, Студия — это все (или почти все).
С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.
Я знаю людей, которые открывают отдельную студию только для TFS, а пишут код и дебагируют в другой студии. И я их понимаю, не хочу смешивать код (и дебагирование) с более другими задачами.
С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.
Я знаю людей, которые открывают отдельную студию только для TFS, а пишут код и дебагируют в другой студии. И я их понимаю, не хочу смешивать код (и дебагирование) с более другими задачами.
И потом ходить по ним, открывая десятками на вкладках. Путаешься в конец. Мне кажется, в этом нет необходимости. Параллельно анализировать больше одной задачи нереально.
Уважаемый lair. Я проводил аудит постоянно и решил это тем, что при checkin разработчики должны были заполнить поля Comment и Check-In Notes. Понятно, что пришлось убеждать народ в необходимости этого дела -).
* Comment
Описание решенных задач, поставленных в JIRA, а также, возможно, не заведенных задач. Пример:
ARIJ-345 Прикрутить к Price интерфейс IComparable
Не видна часть позиций счета Rс резервами при добавлении в груз
Здесь важно иметь не только номера, но и текст задач.
* Детальное описание изменений – обязательное
Четкое и краткое описание изменений и их смысловая нагрузка.
* Изменения в структуре БД
Удаление/создание/изменения таблиц, View, хранимых процедур.
* Улучшения производительности
Описание улучшений в производительности системы, достигнутые при реализации данных изменений.
* Изменения, видимые пользователю
Кратко описываются изменения в пользовательском интерфейсе
* Замечания для группы тестирования
Советы группе тестирования о том, как тестировать внесенные изменения
* Замечания для группы документирования
Советы группе документирования о том, что должно быть изменено в пользовательской документации в связи с данными изменениями
* Comment
Описание решенных задач, поставленных в JIRA, а также, возможно, не заведенных задач. Пример:
ARIJ-345 Прикрутить к Price интерфейс IComparable
Не видна часть позиций счета Rс резервами при добавлении в груз
Здесь важно иметь не только номера, но и текст задач.
* Детальное описание изменений – обязательное
Четкое и краткое описание изменений и их смысловая нагрузка.
* Изменения в структуре БД
Удаление/создание/изменения таблиц, View, хранимых процедур.
* Улучшения производительности
Описание улучшений в производительности системы, достигнутые при реализации данных изменений.
* Изменения, видимые пользователю
Кратко описываются изменения в пользовательском интерфейсе
* Замечания для группы тестирования
Советы группе тестирования о том, как тестировать внесенные изменения
* Замечания для группы документирования
Советы группе документирования о том, что должно быть изменено в пользовательской документации в связи с данными изменениями
Что у вас использовалось в качестве системы управления требованиями и задачами?
Требования — Confluence. Задачи — JIRA.
А в треде речь идет об использовании для этих целей TFS. В этом случае ваши требования несколько (будем честными, очень сильно) избыточны.
Вы сами писали, что вам этого не хватает, я лишь предложил универсальное решение.
Кстати, я не считаю, что оно избыточно.
Можно кликать по строкам истории и справа видеть Related Work Items. Правда, последние 6 checkin notes автоматом там не возникнут -).
Кстати, я не считаю, что оно избыточно.
Можно кликать по строкам истории и справа видеть Related Work Items. Правда, последние 6 checkin notes автоматом там не возникнут -).
Мне не хватает конкретных номеров WI, но копировать их в описание когда у TFS уже есть их хранение — нелепо. Аналогично, нет смысла описывать замечания для групп тестирования и документирования, они должны быть описаны в TFS в соответствующем WI.
Номер WI без темы бесполезен.
Ну, ОК. Double-click на каждой строке вам в помощь. -)
Кстати, у вас нет ни одного checkin без WI?
А вообще, я сейчас вспомнил, что я делал аудит не по истории, а по оповещениям на checkin в почту. Это позволяло (1) видеть не только комментарий, но и checkin notes, (2) понимать, что прошло аудит, что нет (прочитано письмо — прошло), (3) сортировать, например, по людям.
нелепо
Ну, ОК. Double-click на каждой строке вам в помощь. -)
Кстати, у вас нет ни одного checkin без WI?
А вообще, я сейчас вспомнил, что я делал аудит не по истории, а по оповещениям на checkin в почту. Это позволяло (1) видеть не только комментарий, но и checkin notes, (2) понимать, что прошло аудит, что нет (прочитано письмо — прошло), (3) сортировать, например, по людям.
Все-таки логично увидеть все изменения связанные с определенным дефектом. Это сразу позволяет оценить несколько аспектов этой починки.
SVN, кстати, тоже так не показывает, там надо ревизию выбрать сначала.
Еще вы совершенно упускаете My work (хотя он доступен только от Premium и выше).
Согласен. Не знаю что это такое, но теперь попрбую. Спасибо!
Не нашел способа увидеть все измененные файлы (да и в Студии это просто не удобно).
Тривиально: из WI открываете all links, там будут все changeset, которые ассоциировали с этим WI. Дальше по двойному клику на чейнджсете вы получаете полный список всех изменений этого чейнджсета.
Да, я получу список всех изменений этого чейнджсета, но часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).
часто мне необходимо список изменений всего «дефекта» (нескольких чейнджсетов).
«Такой же, но с перламутровыми пуговицами»? А зачем?
Это позволяет мне сразу оценить несколько аспектов починки всего бага, а не одного чейнджсета.
Например, какие проекты были затронуты, а есть ли тесты, на что изменения могут повлиять.
На основании этой информации можно принять другие более конкретные решения.
Например, какие проекты были затронуты, а есть ли тесты, на что изменения могут повлиять.
На основании этой информации можно принять другие более конкретные решения.
А, так это тоже административная проблема. И решается она административными способами.
Правило первое: на одну задачу — один чейнджсет (просто потому, что в норме так и должно быть, если задачи правильно декомпонованы).
Правило второе: даже если чейнджсетов больше одного, любой из них атомарен и безопасен для кода.
Правило третье: тесты (особенно на баги) пишутся до кода.
Сочетание правил (2) и (3) означает, что в любом чейнджсете, если это не рефакторинг, должны быть тесты, а рефакторинг тестами покрывать не надо.
Соответственно, следствие из правила (2) — оценивать надо каждый чейнджсет отдельно, потому что именно он может уйти в другую ветку/на продуктив.
Правило первое: на одну задачу — один чейнджсет (просто потому, что в норме так и должно быть, если задачи правильно декомпонованы).
Правило второе: даже если чейнджсетов больше одного, любой из них атомарен и безопасен для кода.
Правило третье: тесты (особенно на баги) пишутся до кода.
Сочетание правил (2) и (3) означает, что в любом чейнджсете, если это не рефакторинг, должны быть тесты, а рефакторинг тестами покрывать не надо.
Соответственно, следствие из правила (2) — оценивать надо каждый чейнджсет отдельно, потому что именно он может уйти в другую ветку/на продуктив.
Все что вы написали правильно, но что бы поддерживать такой способ нужно просматривать историю, проверять что все выполняют эти правила и т.д. и т.п. Эта работа особенно требует быстрый и удобный поиск, чего как раз и не хватает в TFS
Не, вот поиска эта работа не требует. Она требует банального просмотра каждого cs отдельно.
Не совсем, прежде всего мне надо увидет все изменения дефекта, а не отдельной ревизии.
Например, пишешь в фильтре истории номер дефекта и сразу видишь все ревизии. Сразу понимаешь, что этот человек нарушил правила проекта.
Например, пишешь в фильтре истории номер дефекта и сразу видишь все ревизии. Сразу понимаешь, что этот человек нарушил правила проекта.
Не совсем, прежде всего мне надо увидет все изменения дефекта,
Вы пока так и не объяснили, зачем.
Сразу понимаешь, что этот человек нарушил правила проекта.
Какие именно?
Сразу понимаешь, что этот человек нарушил правила проекта.
Какие именно?
два ревизии на один «дефект», например.
Зайдите в закрытый WI и посмотрите. Это эффективнее, чем проверять список из 180 чекинов на то, что в 99-ом тот же номер, что и в 15-ом.
Не совсем, прежде всего мне надо увидет все изменения дефекта,
Вы пока так и не объяснили, зачем.
Не могу это объяснить в общем. Просто я так начинаю: прежде всего оцениваю что произошло за период времени и выбираю наиболее «интересный» баг или ревизию для дальнейшей работы.
Это никак не относится к сценарию «мне надо увидеть все изменения по WI».
Почему?
Я увидел какой-то WI и он меня почему то заинтересовал.
Набираю его номер в фильтре (SVN) и сразу вижу все релевантные ревизии и изменения.
Я увидел какой-то WI и он меня почему то заинтересовал.
Набираю его номер в фильтре (SVN) и сразу вижу все релевантные ревизии и изменения.
А в TFS вы набираете его номер и сразу видите сам WI, а потом и релевантные изменения.
Вы просто привыкли мыслить версионником, потому что SVN — это версионник. Но в TFS это не так.
Вы просто привыкли мыслить версионником, потому что SVN — это версионник. Но в TFS это не так.
Так я об этом и писал!
Я привык идти от кода, поэтому начинию с истории (лога) кода и дальше добираюсь (если надо) до WI.
В TFS это не так, т.е. (на мой взгляд) TFS менее заточен для программиста (код), чем другие (например SVN).
Я привык идти от кода, поэтому начинию с истории (лога) кода и дальше добираюсь (если надо) до WI.
В TFS это не так, т.е. (на мой взгляд) TFS менее заточен для программиста (код), чем другие (например SVN).
То, что вы описываете — потребность не программиста, а менеджера. Программисту нужно знать текущее состояние кода и причины, которые к нему привели. Т.е., annotate.
я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.
А annoate я использую когда надо быстро найти, кто написал этот фрагмент кода, и в рамках какой деятельности.
А annoate я использую когда надо быстро найти, кто написал этот фрагмент кода, и в рамках какой деятельности.
я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.
И зачем это нужно программисту?
(ну и повторюсь, именно описанный вами сценарий прекрасно реализован, просто надо его начинать от WI)
я начинаю от общего к частностям: вперва сколько ревизий для этого дефекта, где были изменения, какие были изменения.
И зачем это нужно программисту?
У меня есть такие примеры:
— мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
— расследования всяких сложных проблем: что то пошло не так (какие то тесты стали падать, перформанс пострадал, интеграция с другой программы барахлит).
мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
Это делается не программистом, а тимлидом (который, конечно, тоже программист, но это другая часть его функций). И правильно это делать через code review.
расследования всяких сложных проблем
Это делается не по WI, а по всей истории кода сразу.
расследования всяких сложных проблем
Это делается не по WI, а по всей истории кода сразу.
Так я про это и пишу.
Например, попадали тесты, открываешь историю, находишь подозрительную ревизию, откатываешь все ревизии этого дефекта, проверяешь этот тест локально. Красота!
Жалко TFS данного сценария не поддерживает совсем :(.
и делается это одним из обычных программистов.
TFS поддерживает этот сценарий на уровне «попадали тесты — код не попал в репозиторий — красота». Если вы по каким-то причинам не делаете gated check-ins (а зря), то «находишь подозрительное изменение, откатываешь это изменение, проверяешь тест локально». Вы же помните, что все изменения должны быть атомарными?
Как пел классик
Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота». А иногда важнее отдать версию, даже с падающим тестом.
Помню. Только не знаю где есть такая команда, в которой это работает. Может послать туда резюме, раз TFS не поддерживает реальность? ;)
А я живу в реальном мире, Где жизнь весны полна.
Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота». А иногда важнее отдать версию, даже с падающим тестом.
Вы же помните, что все изменения должны быть атомарными?
Помню. Только не знаю где есть такая команда, в которой это работает. Может послать туда резюме, раз TFS не поддерживает реальность? ;)
Все тесты могут бежать много времени (часы) и мы не можем себе позволить «попадали тесты — код не попал в репозиторий — красота».
Читайте Continuous Delivery.
Только не знаю где есть такая команда, в которой это работает.
А если у вас изменения не атомарны, то вам надо откатывать не все изменения по WI, а полностью все состояние репозитория на момент до подозрительного изменения, потому что вы не знаете, как последующие работы повлияли на код.
Читайте Continuous Delivery.Можете посоветовать, что то конкретное?
Просто тесты (быстрые тесты) мы запускаем конечно же на каждый коммит (чек-ин), но даже этот процесс (очередь, компиляция, выполнение тестов) может занять десятки минут.
а полностью все состояние репозитория на момент до подозрительного изменения, потому что вы не знаете, как последующие работы повлияли на код.
так я так и ищу: откатываю подозрительные дефекты, все ревизии не имеет смысла откатывать: я и так знаю, что тесты не падали.
Еще раз: если изменения атомарны, то можно откатывать каждое изменение отдельно. Если изменения не атомарны, то бесполезно отказывать «изменения в рамках WI», надо откатывать все изменения до стабильной линии.
когда я ищу проблему, нет смысла откатывать до стабильной линии: там то все работает.
мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
мне нужно откатывать определенные куски (дефекты), что бы понять какой из них привел к проблеме.
Я не вижу в этом контексте разницы между откаткой WI и откаткой конкретного CS — проблему-то порождает изменение. Поэтому, когда вы ищете, что сломало, надо мыслить чейнжсетами, а не задачами.
Конечно, но тяжело откатить ревизию, если это часть починки бага. Обычно требуется откатить все ревезии одного дефекта.
Обычно требуется откатить все ревезии одного дефекта.
Объясните, почему.
пример из жизни:
— утро (раннее утро)
— в стабильной ветке проблема, которая не дает выпустить билд
— вместо кофе открываю историю
— прохожу последние ревизии
— нахожу кандидата, который создает проблему
— откатываю его, что бы проверить у себя на компьютере
— все равно вижу проблему, потому что эта ревизия завязана на другую ревизию этого же дефекта
— хочу откатить вторую ревизию этого дефекта, что бы только проверить свои подозрения
— между этими двумя ревезиями есть другие ревизии ==> TFS не может откатить две такие ревизии
— дальше идет игра слов, которая не будет интересна в данном контексте
— утро (раннее утро)
— в стабильной ветке проблема, которая не дает выпустить билд
— вместо кофе открываю историю
— прохожу последние ревизии
— нахожу кандидата, который создает проблему
— откатываю его, что бы проверить у себя на компьютере
— все равно вижу проблему, потому что эта ревизия завязана на другую ревизию этого же дефекта
— хочу откатить вторую ревизию этого дефекта, что бы только проверить свои подозрения
— между этими двумя ревезиями есть другие ревизии ==> TFS не может откатить две такие ревизии
— дальше идет игра слов, которая не будет интересна в данном контексте
А теперь сделайте простой мысленный эксперимент: представьте себе, что на CS, который вы откатываете, завязан CS… из другой задачи. Это, надо сказать, совершенно нормальная ситуация в живой системе. И зачем вам теперь операция «откатить все CS по одному WI»?
И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.
И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.
И нет, вы не правы, TFS прекрасно позволяет откатить любое количество CS, просто это надо делать по одному CS за раз.
Секундочку.
Я хочу откатить только на локальном компьютере, что бы проверить. Я не хочу делать чек-ин, пока не проверю. Этого TFS не позволяет (в моем реальном случае между подозрительными ревизиями находились нормальные, которые я не хотел откатывать).
Берем историю. Выбираем произвольный CS, нажимаем Rollback entire changeset, получаем в workspace компенсирующие изменения. Берем следующий произвольный CS, нажимаем Rollback entire changeset, получаем в workspace компенсирующие изменения. Если компенсирующие изменения конфликтуют — вероятно, получаем разрешение конфликта или окно об ошибке (вот это я проверить уже не могу, лень искать такую комбинацию).
И да, я только что это проверил (VS 2012 Update 4, TFS 2012 Update-не-помню).
И да, я только что это проверил (VS 2012 Update 4, TFS 2012 Update-не-помню).
сорри: небольшая, но важная неточность.
Эти две ревизии содержат, по крайней мере, один общий файл.
В этом случае не могу откатить вторую ревизию с сообщением: TF203015: The item «fileName» has an incompatible pending change.
Проверял на двух ревизиях с одним и тем же файлом.
Эти две ревизии содержат, по крайней мере, один общий файл.
В этом случае не могу откатить вторую ревизию с сообщением: TF203015: The item «fileName» has an incompatible pending change.
Проверял на двух ревизиях с одним и тем же файлом.
Это то, о чем я говорю, как о конфликте компенсирующих изменений. В этом случае вам нужно конкретный файл откатить на версию до обоих изменений (если для проверки — то через Get Specific Version, если для починки — то через Rollback to a version).
Глубоко же закопана возможность «Get Specific Version».
Power Tools не содержит такого пункта меню. А в студии этот пункт находится в Advanced.
Но, во-первых, большое спасибо за совет как обойти ограничение на два Rollback!
Теперь рассмотрим мой конкретный сценарий: первая ревизия содержит X файлов, вторая — Y и Z — общие файлы этих двух ревизий.
Так теперь мне придется ручками «откатывать» все файлы из групп X и Y?
Сложновато и опасно где-нибудь ошибиться.
Или я не так понял?
Power Tools не содержит такого пункта меню. А в студии этот пункт находится в Advanced.
Но, во-первых, большое спасибо за совет как обойти ограничение на два Rollback!
Теперь рассмотрим мой конкретный сценарий: первая ревизия содержит X файлов, вторая — Y и Z — общие файлы этих двух ревизий.
Так теперь мне придется ручками «откатывать» все файлы из групп X и Y?
Сложновато и опасно где-нибудь ошибиться.
Или я не так понял?
Глубоко же закопана возможность «Get Specific Version».
Power Tools не содержит такого пункта меню. А в студии этот пункт находится в Advanced.
… или правой кнопкой в истории — Get this version.
Теперь рассмотрим мой конкретный сценарий: первая ревизия содержит X файлов, вторая — Y и Z — общие файлы этих двух ревизий. Так теперь мне придется ручками «откатывать» все файлы из групп X и Y?
Нет, вам придется «ручками» откатывать только общие файлы.
Сложновато и опасно где-нибудь ошибиться.
«Опасно ошибиться» — это диагностика по cherry-picking, когда вы откатываете много файлов в разных наборах изменений, рискуя получить заведомо неконсистентную систему.
Согласитесь, что простой реверт в SVN гораздо более просто и безопасно реализует данный сценарий.
Я понимаю, что хорошо бы не доводить дело до такого сценария, но он случается.
Я понимаю, что хорошо бы не доводить дело до такого сценария, но он случается.
Простой реверт (svn revert) в SVN откатывает локальное состояние, то же самое, что undo в TFS.
Я имею ввиду реверт ревизий из истории
svn merge -r?Ничего «более простого и безопасного» в нем нет, вы получаете неявный мерж нескольих измененных файлов в локальной области.
Это именно то что мне надо. По сравнению с подходом TFS это более понятно и гораздо быстрее.
Это вам более понятно. Потому что вы привыкли к идеологии SVN, а перестраиваться сложно. А я вот, работая с SVN после TFS, долго и мучительно ругался на неоднозначность разрешения конфликтов.
А теперь сделайте простой мысленный эксперимент: представьте себе, что на CS, который вы откатываете, завязан CS… из другой задачи. Это, надо сказать, совершенно нормальная ситуация в живой системе. И зачем вам теперь операция «откатить все CS по одному WI»?
Мой опыт данного проекта, говорит о том, что довольно редко ревизии одного WI завязаны на ревизии другого. А если это так, то почему бы этим не пользоваться?
мониторинг изменений, чтобы обнаружить проблемы на раннем этапе (делается все-таки программистом)
Это делается не программистом, а тимлидом (который, конечно, тоже программист, но это другая часть его функций). И правильно это делать через code review.
Я местный code review еще «не проходил». Так что все впереди. Хотя все равно не понимаю, как это поможет мне реализовать сценарий описанный выше.
Почему вам не кажется, что лучше выбрать наиболее интересный баг по тому, как его заранее оценили? Или как скажет разработчик? Или по рангу-приоритету?
Но зачем, если есть Git!?
Позвольте мне не обсуждать причины перехода на TFS в этом посте.
Кроме того, я не понимаю какие преимущества (кроме локальной истории) в GIT по сравнению с SVN. Я часто и честно пытался это понять (включая хабр и подкаст умпутуна).
Можете объяснить мне на пальцах? Буду бесконечно благодарен.
Кроме того, я не понимаю какие преимущества (кроме локальной истории) в GIT по сравнению с SVN. Я часто и честно пытался это понять (включая хабр и подкаст умпутуна).
Можете объяснить мне на пальцах? Буду бесконечно благодарен.
«Легкие» ветки, слияние, rebase, bisect, stash, rerere — это как минимум.
Я слышал все эти слова.
Но мне бы на пальцах.
В SVN мы работали с бранчами, создавали сколько надо, жили в них сколько надо, возвращали в родную ветки без особых проблем (есть минимальные требования конечно к поддрежки «долгих» веток).
Наверно единственной серьезной проблемой было перенос ветки в главную ветку другой версии.
Так зачем для данного сценария работа GIT?
Но мне бы на пальцах.
В SVN мы работали с бранчами, создавали сколько надо, жили в них сколько надо, возвращали в родную ветки без особых проблем (есть минимальные требования конечно к поддрежки «долгих» веток).
Наверно единственной серьезной проблемой было перенос ветки в главную ветку другой версии.
Так зачем для данного сценария работа GIT?
В git-е делать, менять и удалять бранчи легко и приятно. Это и рождает новый, принципиально недостижимый для SVN/CVS/Perforce/whatever workflow, когда в текущей работе может одновременно сосуществовать сотня бранчей, по одному на каждый исправляемый баг, и отдельно — для каждой новой разрабатываемой фичи. И вся логика работы (в том числе и поиск багов) базирована на этом.
Именно так мы и работали в SVN.
Именно так мы пытаемся работать в TFS, но из-за сложностей свитча, этот путь не такой легкий и приятный.
Именно так мы пытаемся работать в TFS, но из-за сложностей свитча, этот путь не такой легкий и приятный.
На каком основании вы сделали такие выводы? Я легко веду ветки в TFS.
Как мне видится, проблема в том, сколько времени занимает создать и получить ветку на локальном диске. Если получить ветку у себя на компьютере занимает много (думаю начиная с 10 минут это уже много) времени, то такая система управления версиями не поддерживат «быстрые» ветки.
Например, я знаю проект, ветку которого можно получить за минут 20-25 (в локальной сети фирмы) и за гораздо более другие времена, если скачивать через wi-fi иди удаленно.
Одним из способов решения этой проблемы, является механизм переключения существующей локальной папки с одной ветки на другую. В SVN это называется switch. Если ветки не далеко ушли друг от друга, то свитч займет секунды (минуту — в случае удаленной работы).
Не нашел простого и внятного способа в TFS переключить ветки (stackoverflow предлогает только через командый файл с помощью unmap и map). Этот workaround (unmap & map) не быстрый процесс.
Таким образом можно сказать, что TFS не имеет «больших» «быстрых» веток.
Например, я знаю проект, ветку которого можно получить за минут 20-25 (в локальной сети фирмы) и за гораздо более другие времена, если скачивать через wi-fi иди удаленно.
Одним из способов решения этой проблемы, является механизм переключения существующей локальной папки с одной ветки на другую. В SVN это называется switch. Если ветки не далеко ушли друг от друга, то свитч займет секунды (минуту — в случае удаленной работы).
Не нашел простого и внятного способа в TFS переключить ветки (stackoverflow предлогает только через командый файл с помощью unmap и map). Этот workaround (unmap & map) не быстрый процесс.
Таким образом можно сказать, что TFS не имеет «больших» «быстрых» веток.
Таким образом можно сказать, что TFS не имеет «больших» «быстрых» веток.
Ваше утверждение неверно. Для проекта разумного размера создание новой ветки и ее открытие происходит за время, существенно меньшее 10 минут.
Какое именно утверждение не верно?
Что TFS не имеет больших быстрых веток, поскольку (как вы считаете) TFS не позволяет получить новую ветку за время, не превышающее 10 минут.
Ну да.
За сколько можно получить ветку размером 300 мегабайт на свой комп, работая удаленно?
За сколько можно получить ветку размером 300 мегабайт на свой комп, работая удаленно?
За время, равное скачиванию 300Мб на ваш компьютер по сети (в случае Server workspace, про локальные не знаю).
(да, я в курсе, что TFS плохо работает в ocassionally connected-сценариях. Это известное ограничение.)
(да, я в курсе, что TFS плохо работает в ocassionally connected-сценариях. Это известное ограничение.)
Ну так это и говорит, что TFS не поддерживает больших быстрых веток.
Почему же, поддерживает. Ограничение налагает сеть, а не TFS.
SVN обходит ограничения сети, а TFS — нет
Вопрос, ценой чего.
(это как локальные рабочие пространства в TFS, они тоже обходят эти ограничения… но с проблемами)
(это как локальные рабочие пространства в TFS, они тоже обходят эти ограничения… но с проблемами)
Согласен, практически любая вещь имеет свою цену.
Таким образом у TFS очень дорого иметь большие ветки, а SVN гораздо дешевле.
Таким образом у TFS очень дорого иметь большие ветки, а SVN гораздо дешевле.
Неверно. В TFS дорого работать с большими рабочими областями при плохой сети (в общем-то, безотносительно того, ветка это или нет). И, наоборот, если ты сидишь в нормальной сети, то работа с ветками не затруднительна.
Сценарий: сделать новый бранч (размер — 1GB) и получить его на локальном диске
Условия: на локальном диске находится стабильная ветка
Локальная сеть:
SVN — минута с помощью switch
TFS — минимум минут 20 для серверного мода (минут 40 для локального)
Удаленно:
SVN — минуты с помощью switch
TFS — ближе к часу для серверного мода + некоторое количество «обрывов» (т.е. ручками придется запускать процесс несколько раз)
Ну я и делаю выводы: в моем типичном использовании TFS не поддерживает «быструю» работу с ветками.
Условия: на локальном диске находится стабильная ветка
Локальная сеть:
SVN — минута с помощью switch
TFS — минимум минут 20 для серверного мода (минут 40 для локального)
Удаленно:
SVN — минуты с помощью switch
TFS — ближе к часу для серверного мода + некоторое количество «обрывов» (т.е. ручками придется запускать процесс несколько раз)
Ну я и делаю выводы: в моем типичном использовании TFS не поддерживает «быструю» работу с ветками.
Ну да, признаю, на гигабайтных объемах я TFS не тестировал. Но уж простите, я это нормальным сценарием никак назвать не могу.
TFS вообще не подходит для вашего типичного использования, мы уже давно это поняли. Перестаньте уже есть этот кактус.
в моем типичном использовании TFS не поддерживает «быструю» работу с ветками.
TFS вообще не подходит для вашего типичного использования, мы уже давно это поняли. Перестаньте уже есть этот кактус.
Ну так я делюсь, прежде всего, своим опытом (заодно опытом своих коллег).
Кроме того я сразу написал "больших" веток.
Как мне кажется TFVC пользуются только «большие» компании, которые создают серьезный большой продукт. А какой в таком случае должен быть «средний» размер ветки?
Ну да, признаю, на гигабайтных объемах я TFS не тестировал. Но уж простите, я это нормальным сценарием никак назвать не могу.
Кроме того я сразу написал "больших" веток.
Как мне кажется TFVC пользуются только «большие» компании, которые создают серьезный большой продукт. А какой в таком случае должен быть «средний» размер ветки?
Ничего не знаю про «средний» размер ветки, но я сейчас специально ради теста целиком сбранчил одно из наших магистральных решений. Бранчилось оно 3-4 минуты (естественно, это включая время получения на жесткий диск). Размер… с удивлением узнал, что уже больше 2Gb; из которых, правда, собственно исходников — 65Mb, остальное — метаданные и бинарные зависимости. TFS2012, серверный workspace, гигабитная локальная сеть.
3-4 минуты. ЧЯДНТ?
(а, поправка, я бранч не чекинил сразу после этого, возможно, вы еще на этом тратите много времени)
3-4 минуты. ЧЯДНТ?
(а, поправка, я бранч не чекинил сразу после этого, возможно, вы еще на этом тратите много времени)
(а, поправка, я бранч не чекинил сразу после этого, возможно, вы еще на этом тратите много времени)
не совсем понял, что имеется ввиду?
3-4 минуты. ЧЯДНТ?
Это хороший вопрос. Может общее время зависит не только от размера, сети, но и других факторов (удаленность от сервера? скорость локального диска? нагрузка на TFS сервер? и т.п.).
Попробую перемерять и поэкспериментировать.
В любом случае, switch позволяет игнорировать всякие проблемы (сеть, удаленность и т.п.) для получения «большой» ветки, а TFS требует «хороших» условий.
не совсем понял, что имеется ввиду?
Ну, я создавал бранч второго класса, с проставленной галкой «Create local working copies for the new branch». В этом случае создается бранч, который потом нуждается в чекине (в отличие от создания бранча первого класса, когда тот создается на сервере, чекина не требует, зато требует последующего Get latest).
Вот вам поучительные цифры от MS (которые да, сами сидят на TFS). Обратите внимание, что типичный разработчик никогда не держит у себя бранча целиком («a full branch has about 5M files, and a typical dev workspace 250K files», приблизительно 1/20).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пару слов об интеграции в TFS системы управления дефектами с системой управления версиями