С текущим состояним кода — да, Студия — это все (или почти все).
С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.
Я знаю людей, которые открывают отдельную студию только для TFS, а пишут код и дебагируют в другой студии. И я их понимаю, не хочу смешивать код (и дебагирование) с более другими задачами.
Так я об этом и писал!
Я привык идти от кода, поэтому начинию с истории (лога) кода и дальше добираюсь (если надо) до WI.
В TFS это не так, т.е. (на мой взгляд) TFS менее заточен для программиста (код), чем другие (например SVN).
Конечно. Поэтому по номеру можно кликнуть и почитать WI.
Не всегда меня интересует, что написано в WI, а более интересно сколько ревизий, есть ли тесты, какие части проекта затронуты.
Не совсем, прежде всего мне надо увидет все изменения дефекта,
Вы пока так и не объяснили, зачем.
Не могу это объяснить в общем. Просто я так начинаю: прежде всего оцениваю что произошло за период времени и выбираю наиболее «интересный» баг или ревизию для дальнейшей работы.
Позвольте мне не обсуждать причины перехода на TFS в этом посте.
Кроме того, я не понимаю какие преимущества (кроме локальной истории) в GIT по сравнению с SVN. Я часто и честно пытался это понять (включая хабр и подкаст умпутуна).
Можете объяснить мне на пальцах? Буду бесконечно благодарен.
Не совсем, прежде всего мне надо увидет все изменения дефекта, а не отдельной ревизии.
Например, пишешь в фильтре истории номер дефекта и сразу видишь все ревизии. Сразу понимаешь, что этот человек нарушил правила проекта.
Например:
Открываешь вечером историю, сразу видишь кто что сделал сегодня и быстро понимаешь какие баги чинились, какие файлы менялись. Далее, в зависимости от этой информации, изучаешь более конкретно те или иные ревизии.
Все что вы написали правильно, но что бы поддерживать такой способ нужно просматривать историю, проверять что все выполняют эти правила и т.д. и т.п. Эта работа особенно требует быстрый и удобный поиск, чего как раз и не хватает в TFS
едь это позволяет глядя историю кода открыть соответствующий WI.
Зачем? У меня никогда не возникало такого сценария. У меня есть сценарий «мне надо понять, почему в этом месте кода написано такое», и для этого достаточен Annotate.
Оба эти сценария у меня популярны.
Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.
Если вы, как вы говорите, идете от истории, то достаточно кликать на каждый CS и в его ассоциациях смотреть нужные WI.
«достаточно кликать на каждый CS» — в этом то и дело! SVN позволяет не кликать на каждый, а видеть колонку со всеми номерами дефектов, далее фильтровать ревизии по номеру дефекта и видеть все файлы выбранных ревизий. Это сильно экономит время!
С бранчами, историей, аннотацией, свитчами и многим другим студия далеко не основной инструмент.
Я знаю людей, которые открывают отдельную студию только для TFS, а пишут код и дебагируют в другой студии. И я их понимаю, не хочу смешивать код (и дебагирование) с более другими задачами.
Я привык идти от кода, поэтому начинию с истории (лога) кода и дальше добираюсь (если надо) до WI.
В TFS это не так, т.е. (на мой взгляд) TFS менее заточен для программиста (код), чем другие (например SVN).
Почему?
Я увидел какой-то WI и он меня почему то заинтересовал.
Набираю его номер в фильтре (SVN) и сразу вижу все релевантные ревизии и изменения.
Не всегда меня интересует, что написано в WI, а более интересно сколько ревизий, есть ли тесты, какие части проекта затронуты.
Но все-таки легче «заставить» писать хотя бы номер, чем нормальные комментарии.
Не могу это объяснить в общем. Просто я так начинаю: прежде всего оцениваю что произошло за период времени и выбираю наиболее «интересный» баг или ревизию для дальнейшей работы.
два ревизии на один «дефект», например.
Согласен. Но прежде всего мне надо оценить в общем состоянии истории, а потом заняться конкретными дефектами или ревизиями.
Кроме того, я не понимаю какие преимущества (кроме локальной истории) в GIT по сравнению с SVN. Я часто и честно пытался это понять (включая хабр и подкаст умпутуна).
Можете объяснить мне на пальцах? Буду бесконечно благодарен.
Например, пишешь в фильтре истории номер дефекта и сразу видишь все ревизии. Сразу понимаешь, что этот человек нарушил правила проекта.
Открываешь вечером историю, сразу видишь кто что сделал сегодня и быстро понимаешь какие баги чинились, какие файлы менялись. Далее, в зависимости от этой информации, изучаешь более конкретно те или иные ревизии.
Оба эти сценария у меня популярны.
Просто история позволяет быстро увидеть все-изменения и понять какие баги решаются этими изменения.
«достаточно кликать на каждый CS» — в этом то и дело! SVN позволяет не кликать на каждый, а видеть колонку со всеми номерами дефектов, далее фильтровать ревизии по номеру дефекта и видеть все файлы выбранных ревизий. Это сильно экономит время!