Комментарии 39
а зачем? :)
+49
Еще надо статью про то как мигирировать с Меркуриала на ТФС. Аха. Все так и рвутся.
+29
Если использовать TFS только как систему контроля версий- действительно переходить не зачем. Но это как принтер-сканер-копир использовать как подставку для цветов.
На работе на TFS делались билды, после каждого чекина. Помоему круто.
Вчера был на конференции, как использовать Scrum на TFS… тоже очень понравилось.
Смысл то TFS- это контроль версий+багтрекер+билды+ администрирование ролей+ все эти отчеты для всех, кому они там нужны и тп.
Если использовать только, как source control, то svn-git более чем хватит.
На работе на TFS делались билды, после каждого чекина. Помоему круто.
Вчера был на конференции, как использовать Scrum на TFS… тоже очень понравилось.
Смысл то TFS- это контроль версий+багтрекер+билды+ администрирование ролей+ все эти отчеты для всех, кому они там нужны и тп.
Если использовать только, как source control, то svn-git более чем хватит.
+3
На работе на TFS делались билды, после каждого чекина.
Это ответсвенность билд сервера, и наверное легче сказать у какого билд сервера щас нема этой фитчи.
Если по теме, то мне в TFS контроле версий, шелвинг очень нравится.
+7
К сожалению, unshelve затирает изменения, если таковые произошли в этом файле с момента shelve. Надо очень аккуратно.
0
TFS это кошмар проджект менеджера. Каждый раз когда мне приходится открывать я ненавижу его больше больше.
+9
Тут речь идет про ту его часть которая контроль версий. Мне достаточно сложно представить зачем проджект менеджер ее открывает.
0
Я конечно больше про управление задачами, но TFS позиционируется как решение все в одном, поэтому нельзя коньтроль версий отделить от других частей TFS.
0
Или вы хотите купить лицензию TFS сервера, которая стоит около 3000 долларов США (если я не ошибаюсь), и пользовататься только контролем версий?
+2
Ну официальный ответ я думаю тут был бы
Верхняя часть планирования осуществляется через project server и microsoft project 2010, а далее уже после проведения бизнес планирования, уже частично декомпозированные задачи спускаются в tfs, где уже конкетно команда(разработчики, тестеры, архитекторы и все кому студия родной инструмент) занимается дальнейшей деятельностью.
Мол купите 2 инструмента и будет вам счастье.
По крайней мере, на конференции по scrum на vs2010 был примерно такой ответ.
Верхняя часть планирования осуществляется через project server и microsoft project 2010, а далее уже после проведения бизнес планирования, уже частично декомпозированные задачи спускаются в tfs, где уже конкетно команда(разработчики, тестеры, архитекторы и все кому студия родной инструмент) занимается дальнейшей деятельностью.
Мол купите 2 инструмента и будет вам счастье.
По крайней мере, на конференции по scrum на vs2010 был примерно такой ответ.
-1
это в идеале, на практике даже программерам удобнее написатьемеил чем создать новую таску в TFS. Microsoft как всегда сделала гибкую платформу пользоваться которой просто не удобно
+3
>даже программерам удобнее написать емеил
Не всегда правда. Если разработчиков всего один-два — тогда верно, пушкой по воробьям получается.
Но когда команда большая: надо написать письмо тимлиду, он пересылает разработчику, разработчик исправляет, пишет тестеру что готово, тестер пишет что не все исправлено, разработчик доделывает, опять пишет тестеру, тестер одобряет, возвращает тимлиду, потом пишут PMу. По желанию можно добавить еще одно звено: «заказчик», если эта ошибка пришла от него. Далее умножаем все это на количество ошибок.
Получается куча писем, а в TFSе за это два комбобокса отвечают: статус ошибки и кому поручено.
PMу и заказчику даже клиента ставить не надо себе. Есть веб интерфейс для простых операций.
Так что все от размеров проекта, требований и команды зависит.
Не всегда правда. Если разработчиков всего один-два — тогда верно, пушкой по воробьям получается.
Но когда команда большая: надо написать письмо тимлиду, он пересылает разработчику, разработчик исправляет, пишет тестеру что готово, тестер пишет что не все исправлено, разработчик доделывает, опять пишет тестеру, тестер одобряет, возвращает тимлиду, потом пишут PMу. По желанию можно добавить еще одно звено: «заказчик», если эта ошибка пришла от него. Далее умножаем все это на количество ошибок.
Получается куча писем, а в TFSе за это два комбобокса отвечают: статус ошибки и кому поручено.
PMу и заказчику даже клиента ставить не надо себе. Есть веб интерфейс для простых операций.
Так что все от размеров проекта, требований и команды зависит.
0
Если команде нужны билды после каждого коммита, то это отлично настраивается на том же TeamCity поверх любого source control. То же самое и с багтрекингом и прочим — было бы желание.
А если не трогать остальных аспектов, то для разработчика лучше всего именно распределённые системы контроля версий по сравнению с обычными (кто пробовал и то и то, те знают).
В общем утверждение таково: да, TFS несомненно лучше, чем SVN и стоит того, но если решили выезжать, то лучше сразу на DVCS.
А если не трогать остальных аспектов, то для разработчика лучше всего именно распределённые системы контроля версий по сравнению с обычными (кто пробовал и то и то, те знают).
В общем утверждение таково: да, TFS несомненно лучше, чем SVN и стоит того, но если решили выезжать, то лучше сразу на DVCS.
+3
Крута было бы в TFS прикрутили DVCS (Меркуриал например). Получился бы такой себе комбаин все в одном флаконе. Заодно и решилась бы проблема инсталяции Меркуриала под Виндой.
0
Какие же вы счастливые люди, что у вашего проекта можно сделать билд после каждого коммита. У нас билд занимает порядка восьми часов, тут есть о чем подумать.
+4
Простите за откровенность, но вы похожи на зомби :)
-1
Статья как мигрировать с TFS на SVN/Hg/Git была бы куда полезнее. Сейчас на проекте TFS клиента — это пц просто.
+16
А расскажите об обнаруженных минусах TFS, пожалуйста.
+8
Я не говорю про весь TFS (как система он, наверное, хорош — у меня пока мало опыта), но вот в контроле версий МС, как всегда пошёл своим путём — вот зачем им надо было привычные операции update/commit называть по другому: checkout/checkin. Я вот до сих пор привыкнуть не могу.
Атрибут ReadOnly у файлов раздражает, студия его, конечно, автоматически снимает, но не всегда же только из студии с файлами работают.
Недавно пришлось проект прицеплять к уже добавленному в контроль версий, дык по-человечески это сделать так и не удалось, пришлось студии скомандовать «ну и что, что у тебя на сервере есть такие файлы, а я уверен, что мои правильные! Делай как я сказал!» чтобы таки достигнуть цели.
Атрибут ReadOnly у файлов раздражает, студия его, конечно, автоматически снимает, но не всегда же только из студии с файлами работают.
Недавно пришлось проект прицеплять к уже добавленному в контроль версий, дык по-человечески это сделать так и не удалось, пришлось студии скомандовать «ну и что, что у тебя на сервере есть такие файлы, а я уверен, что мои правильные! Делай как я сказал!» чтобы таки достигнуть цели.
+2
> вот зачем им надо было привычные операции update/commit называть по другому: checkout/checkin.
По-моему, так только в svn. В Git, например, они вообще называются push/pull :)
По-моему, так только в svn. В Git, например, они вообще называются push/pull :)
0
А двое человек могут одновременно редактировать один файл?
0
НЛО прилетело и опубликовало эту надпись здесь
Сколько у вас разработчиков работает над проектом? И каков размер самого проекта?
0
В чем суть проблем с которыми вы столкнулись? Может быть вам тоже подойдет решение с svnbridge?
+2
Эту картинку нужно вставить в начале поста:
![](https://habrastorage.org/r/w780q1/storage/habraeffect/48/95/48954dc5f2d5a3c24a5cdb7ae28ed544.jpg)
![](https://habrastorage.org/storage/habraeffect/48/95/48954dc5f2d5a3c24a5cdb7ae28ed544.jpg)
+12
Интересно, неужели кто-то реально использует TFS?
+15
исключительно религионзные споры и плюсование сообщений любителей сборных комбайнов, рождающих кучи конфликтов
TFS мощная штука для крупных проектов, где работают не 10-15 человек, заливают каждые 10 минут, билдят, запускают авто прогон тестов на нескольких средах, тимлиды производят кодревью, а не кодят вместе с джунеорами, отслеживаниют таски, проводят интеграцию тасков с результатами тестирования (с комментариями системы и стектрейсом, а не ленивого тестировщика «не работает»). И писать комментарии «а за чем?» это всё равно что ходить на работу через дорогу от дома и удивляться том, как так люди стоят в пробках по 2 часа.
TFS мощная штука для крупных проектов, где работают не 10-15 человек, заливают каждые 10 минут, билдят, запускают авто прогон тестов на нескольких средах, тимлиды производят кодревью, а не кодят вместе с джунеорами, отслеживаниют таски, проводят интеграцию тасков с результатами тестирования (с комментариями системы и стектрейсом, а не ленивого тестировщика «не работает»). И писать комментарии «а за чем?» это всё равно что ходить на работу через дорогу от дома и удивляться том, как так люди стоят в пробках по 2 часа.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мигрировать с SVN на TFS