Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 154
Про практику работы Git в TFS было бы актуальнее.
Я работал и SourceSafe и c TFS и с Git (но на bitbucket, не в TFS). Играл с HG.
Git пока что фаворит.
И Microsoft это понимает. И я не один такой. Неспроста так они ASP.Net на github.com/aspnet выложили. А не на родной codeplex.
Я работал и SourceSafe и c TFS и с Git (но на bitbucket, не в TFS). Играл с HG.
Git пока что фаворит.
И Microsoft это понимает. И я не один такой. Неспроста так они ASP.Net на github.com/aspnet выложили. А не на родной codeplex.
с удовольствием написал бы, но нет у меня такой практики :(
некоторые фичи TFS (e.g. code-review) не работают в случае использования гита — msdn.microsoft.com/en-us/library/vstudio/ms181368.aspx#tfvc_or_git_details
родной студийный модуль для гита не работает с SSH
в общем, сравнивали стек Atlassian и TFS — предсказуемо выбрали первое
родной студийный модуль для гита не работает с SSH
в общем, сравнивали стек Atlassian и TFS — предсказуемо выбрали первое
Я в свое время так и не понял, какие вообще преимущества у TFS (и есть ли они вообще).
есть люди, которые считают, что TFS это полный ALM и поэтому можно потерпеть его систему управлениями версий
Для разработчиков они стремятся к 0, т.к. число достойных аналогов очень велико. Но решения в вопросах на что покупать лицензию часто зависит от людей, которым важно видеть ситуацию по проекту в режиме «реального времени». И тут Microsoft есть, что продать — красивые диаграммы, отчеты по трудозатратам, интеграция с Microsoft Project и Microsoft SharePoint, и т.д.
Сквозная интеграция версионник — трекер — билд для тех, кому неохота возиться руками. И полная поддержка в студии.
Что-то мне кажется, вы поменяли шило на мыло. На предыдущей работе был SVN, хотелось плакать, на предпредыдущей работе был как раз TFS — хотелось плакать кровавыми слезами. Сейчас во всех проектах использую HG (и на работе и в личных) — счастью нет предела, хотя есть конечно некоторые неприятные моменты. Иногда приходится пользоваться Гитом, но что-то оно не по мне, особенно после навыка работы с hg, хотя в студенческие годы Гитом пользовался весьма активно.
Если бы «шило на мыло»; (
Я честно хотел понять, чем git или hg лучше чем svn. Кроме локальной истории, что еще?
Я думаю, достаточно однажды попытаться смерджить две интенсивно «разрабатываемых» ветки в SVN и сделать то же в HG. Разница будет видна невооруженным глазом.
Мы постоянно создаем ветки, работаем в них дни — недели — месяцы, сливаем с главного бранча, возвращем в главный бранч: никаких особых проблем не видим.
Сложности возникают когда ветку, созданную в одной версии надо вернуть в другую версию
Сложности возникают когда ветку, созданную в одной версии надо вернуть в другую версию
Но ведь не всегда есть лишь один главный бранч и много временных подбранчей. Вот если у вас default и stable и последний отстаёт от первого на, скажем, две недели, а пул риквесты бывают как критические (в стейбл), так и нет (в дефолт) и default со stable постоянно перемердживаются — вот тогда чувствуется превосходство hg. Я сам был ярым фанатом SVN, пробовал и гит (через ряд причин он мне подошёл), но когда попробовал меркуриал — сел на нем твёрдо. Я не говорю, что одно лучше другого: я просто считаю, что меркуриал более «продвинутый» для сложных методик разработки.
Ветвление! В hg ветки очень прозрачная штука. На самом деле в hg как таковых веток нет, у каждой ревизии просто проставляется тег с именем ветки, а также номер ревизии на базе которой сделан коммит. А граф потом строится по этим меткам.
Отсутствие необходимости в сервере при коммите -> более частые и независимые коммиты. Очень удобно, т.к. нередко бывают ситуации, когда я делаю коммиты нерабочего/некомпилирующегося кода, просто для того чтобы зафиксировать состояние файлов, при этом очень нежелательно, чтобы этот код попал в таком виде в центральный репозиторий, например, изза того, что автоматом запустится билд.
Ну и плюс скорость коммита у svn зависит напрямую от скорости доступа к центральному репозиторию, помню на старой работе бывало коммиты проходили минут по 5.
Насколько помню, если в svn вы находитесь в одной из общих веток, хотите сделать коммит, а ветка изменена на сервере, то мерж неизбежен, а мерж нередко довольно муторная операция, которой в данный момент очень не хочется заниматься. В hg вы коммититесь в текущую ветку и не паритесь. А мерж между локальной версией и удаленной версией одной и той же ветки сделаете, когда будет настроение, причем мержить можно как из удаленной в свою, так и из своей в удаленную (помним, что «своя» и «удаленная» — это одна и та же именованная ветка).
Отсутствие необходимости в сервере при коммите -> более частые и независимые коммиты. Очень удобно, т.к. нередко бывают ситуации, когда я делаю коммиты нерабочего/некомпилирующегося кода, просто для того чтобы зафиксировать состояние файлов, при этом очень нежелательно, чтобы этот код попал в таком виде в центральный репозиторий, например, изза того, что автоматом запустится билд.
Ну и плюс скорость коммита у svn зависит напрямую от скорости доступа к центральному репозиторию, помню на старой работе бывало коммиты проходили минут по 5.
Насколько помню, если в svn вы находитесь в одной из общих веток, хотите сделать коммит, а ветка изменена на сервере, то мерж неизбежен, а мерж нередко довольно муторная операция, которой в данный момент очень не хочется заниматься. В hg вы коммититесь в текущую ветку и не паритесь. А мерж между локальной версией и удаленной версией одной и той же ветки сделаете, когда будет настроение, причем мержить можно как из удаленной в свою, так и из своей в удаленную (помним, что «своя» и «удаленная» — это одна и та же именованная ветка).
Мы много и активно работаем с ветками: особых проблем не видим
Git достаточно использовать пару часов, чтобы понять, что в svn веток нет.
если бы вы привели бы один пример (только реальный), который ярко это демонстрирует, я был бы очень благодарен.
Пример достаточно простой. Спрошу вас пару вопросов.
Как много у вас народу сидит на персональных ветках?
Как легко вам перепрыгнуть с реализации одной фичи на другую?
В случае с git — у разработчиков очень простой workflow — создаешь branch на feature. Работаешь спокойно на ней, делаешь commits в любое время в свой собственный branch без испуга, что можешь кого-то сломать. То есть можешь работать над features поэтапно. А так же в любой момент можешь засинхронизировать свой branch с branch какого-нибудь coworker.
Если вас попросят быстро сделать fix для продукта в главной ветке — делаешь спокойно staging, это что-то shelveset, но заметьте, что в отличие от SVN/TFS у вас в branch может быть уже с 10 commits, и последний stage с какими-то недоделанными штуками. В случае SVN/TFS у вас будет один огромный недоделанный shelveset (если не используете персональных branch). Так вот, делаешь staging — и создаешь branch для фикса этого bug из какого-нибудь другого branch — и спокойно над ним работаете. Если оказывается, что вас опять просят переброситься куда-нибудь — спокойно делаете.
Заметьте еще, что вы всегда находитесь в одной папке, когда меняете branch — не нужно переоткрывать редакторы и т.п.
Как много у вас народу сидит на персональных ветках?
Как легко вам перепрыгнуть с реализации одной фичи на другую?
В случае с git — у разработчиков очень простой workflow — создаешь branch на feature. Работаешь спокойно на ней, делаешь commits в любое время в свой собственный branch без испуга, что можешь кого-то сломать. То есть можешь работать над features поэтапно. А так же в любой момент можешь засинхронизировать свой branch с branch какого-нибудь coworker.
Если вас попросят быстро сделать fix для продукта в главной ветке — делаешь спокойно staging, это что-то shelveset, но заметьте, что в отличие от SVN/TFS у вас в branch может быть уже с 10 commits, и последний stage с какими-то недоделанными штуками. В случае SVN/TFS у вас будет один огромный недоделанный shelveset (если не используете персональных branch). Так вот, делаешь staging — и создаешь branch для фикса этого bug из какого-нибудь другого branch — и спокойно над ним работаете. Если оказывается, что вас опять просят переброситься куда-нибудь — спокойно делаете.
Заметьте еще, что вы всегда находитесь в одной папке, когда меняете branch — не нужно переоткрывать редакторы и т.п.
>> В моих условиях это берет максиму несколько минут.
Я раньше работал с svn. Теперь используем git. И вот такое про «несколько минут» читать особенно дико, хотя весьма знакомо — раньше сам так делал.
Переключение между ветками в git занимает несколько секунд.
Я раньше работал с svn. Теперь используем git. И вот такое про «несколько минут» читать особенно дико, хотя весьма знакомо — раньше сам так делал.
Переключение между ветками в git занимает несколько секунд.
А я вот посидел полгода на гите, и мне показалось что для многих проектов SVN лучше — за счет отлично работающего Tortoise SVN (когда для GIT нет простых и удобных утилит), и просто за счет того что в SVN нет ненужных сущностей.
Да, в GIT/HG хорошо работают бранчи. Но бранчи далеко не всем нужны. Мне вообще больше нравится процесс, когда прод ставится максимально часто, есть постоянно работающий trunk, близкий по стабильности к продакшну, и 90% коммитов летит сразу в транк. При деплое в прод, код ответвляется, и иногда туда кидаются патчи чтобы пофиксить что-то срочное.
Короче trunk me tender, trunk me sweet, never let me branch.
Такое, безусловно, никогда не сработает для open-source проектов — где можно наделать веток, и делиться pull-request-ами. Там GIT очень хорош. Но когда бранчи не надо — там идеология GIT только мешается.
Да, в GIT/HG хорошо работают бранчи. Но бранчи далеко не всем нужны. Мне вообще больше нравится процесс, когда прод ставится максимально часто, есть постоянно работающий trunk, близкий по стабильности к продакшну, и 90% коммитов летит сразу в транк. При деплое в прод, код ответвляется, и иногда туда кидаются патчи чтобы пофиксить что-то срочное.
Короче trunk me tender, trunk me sweet, never let me branch.
Такое, безусловно, никогда не сработает для open-source проектов — где можно наделать веток, и делиться pull-request-ами. Там GIT очень хорош. Но когда бранчи не надо — там идеология GIT только мешается.
Ну git не только ветками хорош (хотя если говорить о разработке небольшой закрытой группой — то git flow не помешает).
объясните мне пожалуйста в чем проблемы веток в SVN? а то мы их пользуем, а проблемы не понимаем :(
Я на SVN не наговариваю — в SVN ветки вполне неплохо работают. Но представь себе кашу из веток масштаба github — когда популярные проекты по сто раз форкнули, туда накомиттили, и потом это всё мердится, ребейзится, пулл-реквестится, и назад как-то сводится воедино. Такое всё-таки не для SVN. А держать stable/trunk и еще пару веток для разработки — это без проблем и на SVN конечно.
Пример понятен. Просто я еще с таким не сталкивался на практике.
Интересно, я уверен, что таких популярых проектов не так много, почему же очень много людей так востаргаются ветками гита?
Интересно, я уверен, что таких популярых проектов не так много, почему же очень много людей так востаргаются ветками гита?
Для того, чтобы ругать SVN не обязательно им пользоваться, достаточно услышать, как его ругают. Я вот уже довольно давно убеждён, что с ветвлением в SVN плохо, хотя сам почти им не пользовался. Правда, и в дискуссии на стороне противников SVN обычно не встреваю или говорю только о том, что видел — медленный checkout, ещё более медленный log (при работе с репозиторием, хостящимся не на своей машине и даже не в локальной сети, конечно), нет переписывания истории по запросу клиента (администратор вроде как может, для моих нужд достаточно было просто удалить репозиторий и создать его заново скриптом).
Если я правильно помню что такое граммофон и кассетный магнитофон, вы считаете, что TFS лучше SVN? Можно узнать чем именно?
Вы это зря такой пример привели, виниловые проигрыватели пользуются большой популярностью у профессионалов :) www.amazon.com/b?node=3003611
TFS (система контроля версий) это не совсем система контроля версий — это часть VS. После SVN это несколько напрягает. Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Во-первых, TFS — это не только система контроля версий, а это система управления жизненным циклом проекта, где контроль версий — это малая толика всего что есть в TFS.
Во-вторых, TFS — это не часть VS. Да, в VS есть встроенный плагин для доступа к TFS. Но это только плагин, такой же как и VisualSVN и любой другой. Можно поставить плагин, например, к XCode или Eclipse и спокойно работать с репозиторием в TFS.
Остальная статья примерно в таком же духе. Чтобы писать про впечатления, надо хотя бы разобраться в вопросе. Вообще не понимаю как вы решились перевести большой проект на TFS, если даже не знаете что такое TFS.
… система управления жизненным циклом проекта, где контроль версий — это малая толика всего что есть в TFS.
Есть мнение, что без самого исходного кода (который таки хранится в системе контроля версий) проекта-то и не состоится. Посему эта система все ж таки на первом месте по важности.
Во-первых, TFS — это не только система контроля версий, а это система управления жизненным циклом проекта, где контроль версий — это малая толика всего что есть в TFS.
ну так я про это и говорю, TFS — это не система контроля версий.
Интересно, а можно поставить плагин к notepad++, что бы в «серверном» режиме менять что то в группе файлов?
Интересно, а как без студии посмотреть какие есть бранчи на сервере?
Интересно, а как без студии можно принести бранч с сервера на локальный диск?
Остальная статья примерно в таком же духе. Чтобы писать про впечатления, надо хотя бы разобраться в вопросе. Вообще не понимаю как вы решились перевести большой проект на TFS, если даже не знаете что такое TFS.
я готов разделить ваше возражение, но если можно по пунктам. могли бы вы конкретно опубликовать возражения и на все остальные пункты?
кстати:
— вопрос процесса принятия решение о смене системы управления версий позвольте вынести за рамки этого поста.
— я честно пытаюсь разобраться в вопросе и этот пост часть этого разбирательства.
по поводу разбирательства. вот что думают «лучшие люди коллектива» (с), включая Martin Fowler про TFS
«We continue to see teams run into productivity problems attempting to use TFS as a version control system. Teams that want to practice frequent code checkins, a core part of continuous integration, have found its heavyweight approach significantly drains productivity. This often leads to teams checking in less frequently, causing more problematic merges. We recommend tools such as Git, Perforce, and Subversion instead.»
а недавно в твиттере прошел слух, что TFS будет преимущественно поддерживать Git. многие даже поставили охлаждать шампанское по этому поводу, но microsoft невинно отбивается и кивает на прессу Is Microsoft abandoning TFVC in favor of Git?
Попробую ответить на некоторые вопросы:
Вопрос: Интересно, а как без студии посмотреть какие есть бранчи на сервере? Интересно, а как без студии можно принести бранч с сервера на локальный диск?
Ответ: TFS Explorer EveryWhere либо через web-версию (если она развернута).
Вопрос: Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия
Ответ: TFS — это сервер и VS подключается к нему. Проект привязывается к одному TFS серверу. Смысл держать несколько серверов?
Вопрос: ReadOnly
Ответ: Можно настроить автоматический Check Out при редактировании файла.
Вопрос: Microsoft Visual Studio Team Foundation Server 2013 Power Tools
Ответ: Данный Extension ставиться в зависимости от версии VS.
Вопрос: в это время запускаю «Get Selected Item(s)» получаю ошибку «TF400324
Ответ: Source Explorer в VS позволяет делать все необходимые операций с файлами. Т.е. можно избежать такой ошибки.
Вопрос: Интересно, а как без студии посмотреть какие есть бранчи на сервере? Интересно, а как без студии можно принести бранч с сервера на локальный диск?
Ответ: TFS Explorer EveryWhere либо через web-версию (если она развернута).
Вопрос: Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия
Ответ: TFS — это сервер и VS подключается к нему. Проект привязывается к одному TFS серверу. Смысл держать несколько серверов?
Вопрос: ReadOnly
Ответ: Можно настроить автоматический Check Out при редактировании файла.
Вопрос: Microsoft Visual Studio Team Foundation Server 2013 Power Tools
Ответ: Данный Extension ставиться в зависимости от версии VS.
Вопрос: в это время запускаю «Get Selected Item(s)» получаю ошибку «TF400324
Ответ: Source Explorer в VS позволяет делать все необходимые операций с файлами. Т.е. можно избежать такой ошибки.
Ответ: TFS Explorer EveryWhere либо через web-версию (если она развернута).
как я понимаю, это командная строка. несколько не удобный способ просматривать ветки на сервере. и явно берет больше времени.
Вопрос: Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия
Ответ: TFS — это сервер и VS подключается к нему. Проект привязывается к одному TFS серверу. Смысл держать несколько серверов?
у меня стоит 3 студии на моем локальном компьютере. каждая студия приносит свой клиент TFS.как студия VS2010 будет работать с server режимом, если на сервере стоит TFS2012?
Вопрос: ReadOnly
Ответ: Можно настроить автоматический Check Out при редактировании файла.
можно, пока работаешь через студию. а вот открыл я какой-нибудь notepad++ поискал что то в файла и хочу отредактировать парочку из них и вернуть на сервер?
Вопрос: Microsoft Visual Studio Team Foundation Server 2013 Power Tools
Ответ: Данный Extension ставиться в зависимости от версии VS.
у меня на компьютере 3 студии. какой Power Tools ставить?
Вопрос: в это время запускаю «Get Selected Item(s)» получаю ошибку «TF400324
Ответ: Source Explorer в VS позволяет делать все необходимые операций с файлами. Т.е. можно избежать такой ошибки.
можно конечно избежать почти любой ошибки (особенно когда много шишек набьешь). но все это требует дополнительных усилий и времени. что я и хотел подчеркнуть для тех, кому придется переходить с SVN на TFS.
Из-за особенностей хабра не смог нормально оформить свой ответ.
— Согласен, TFS Explorer EveryWhere не подходит. Можно установить отдельно Team Explorer: social.msdn.microsoft.com/Forums/vstudio/en-US/82581187-8213-42a4-a56c-02dac3c82ecb/manage-source-the-team-foundation-server-control-without-visual-studio?forum=tfsgeneral
Веб-версия позволяет и получить код, и посмотреть бранчи.
— Совместимость клиентов Team Foundation и Team Foundation Server: msdn.microsoft.com/ru-ru/library/dd997788.aspx
— Nodepad++: либо писать plugin, либо (что более правильно в случае использования TFS) использовать VS для поиска и редактирования.
— У меня 3 версии VS (2010, 2012, 2013): стоят 2 PowerTools (2012, 2013). Windows Extension поставлен только у Power Tools 2012
— При переходе к TFS лучше всё делать в рамках VS, имхо.
— Согласен, TFS Explorer EveryWhere не подходит. Можно установить отдельно Team Explorer: social.msdn.microsoft.com/Forums/vstudio/en-US/82581187-8213-42a4-a56c-02dac3c82ecb/manage-source-the-team-foundation-server-control-without-visual-studio?forum=tfsgeneral
Веб-версия позволяет и получить код, и посмотреть бранчи.
— Совместимость клиентов Team Foundation и Team Foundation Server: msdn.microsoft.com/ru-ru/library/dd997788.aspx
— Nodepad++: либо писать plugin, либо (что более правильно в случае использования TFS) использовать VS для поиска и редактирования.
— У меня 3 версии VS (2010, 2012, 2013): стоят 2 PowerTools (2012, 2013). Windows Extension поставлен только у Power Tools 2012
— При переходе к TFS лучше всё делать в рамках VS, имхо.
Если суммровать все ответы, то получается, что TFS это не отделимая часть студии и лучше всего (или все равно не удобно делать по другому) работать только через студию.
Так я про это и говорю. так что тут мы с вами нашли общий язык.
Просто я считаю это недостатком (после длительного опыта работы с SVN).
И даже в работе через студию отсутствуют некоторые вещи, которыми пользуешся работая с SVN.
Так я про это и говорю. так что тут мы с вами нашли общий язык.
Просто я считаю это недостатком (после длительного опыта работы с SVN).
И даже в работе через студию отсутствуют некоторые вещи, которыми пользуешся работая с SVN.
лучше всего (или все равно не удобно делать по другому) работать только через студию.
Это утверждение уже не вполне верно: есть вещи, которые удобнее делать через веб-интерфейс.
TFS это не отделимая часть студии
А это утверждение неверно вообще.
дело в том, что TFS командной строки инсталлирован под папкой соответствующей студии. как это понимать?
если в мире SVN: есть один независимый инструмент командной строки, один плагин для Windows Explorer и один плагин для всех версий студии.
то в мире TFS на мой взгляд все эти инструменты привязаны к соответсвующей студии.
если в мире SVN: есть один независимый инструмент командной строки, один плагин для Windows Explorer и один плагин для всех версий студии.
то в мире TFS на мой взгляд все эти инструменты привязаны к соответсвующей студии.
дело в том, что TFS командной строки инсталлирован под папкой соответствующей студии. как это понимать?
Это не «TFS командной строки», а утилиты командной строки для работы с TFS. Клиент.
Вы просто не понимаете, как устроено то, что вы называете «студия». VS состоит, грубо говоря, из оболочки (Visual Studio Shell) и произвольного количества плагинов, которые в нее ставятся (таким плагином может быть кусок для работы с C#, кусок для работы с SQL или кусок для работы с TFS).
Когда вы ставите TFS-клиент (GUI), на ваш компьютер автоматически ставится оболочка VS, в которой работает этот TFS-клиент. Это не значит, что у вас есть студия — это значит, что у вас есть оболочка. Соответственно, утилиты командной строки будут в подпапке этой оболочки (потому что так устроена модель развертывания, не спрашивайте, зачем).
в мире TFS на мой взгляд все эти инструменты привязаны к соответсвующей студии.
Не к студии. К оболочке. Ну да, это данность такая, ничего плохого в ней нет.
я давно понимаю, что я не понимаю TFS, поэтому и спрашиваю у тех кто понимает.
TFS клиент привязан не к студии, а к оболочке. ок. какая принципильаная разница?
SVN командной строки не привязан к оболочке студии, поэтому наличие привязки удивляет. Зачем его вообще куда то привязывать?
TFS клиент привязан не к студии, а к оболочке. ок. какая принципильаная разница?
SVN командной строки не привязан к оболочке студии, поэтому наличие привязки удивляет. Зачем его вообще куда то привязывать?
какая принципильаная разница?
Лицензии.
Зачем его вообще куда то привязывать?
Не «зачем», а «почему». Потому что вы не ставили отдельно только командную строку (я даже не уверен, что это можно сделать), вы ставили клиент целиком. А он сначалала ставит GUI, а потом, в качестве бонуса, командную строку.
Ок.
TFVC не имеет независимого клиента командной строки, а является частью некой оболочки.
Так я про это с самого начала и говорю. Конечно сейчас я бы уточинил TFVC (а не TFS), VS оболчка (а не VS).
TFVC не имеет независимого клиента командной строки, а является частью некой оболочки.
Так я про это с самого начала и говорю. Конечно сейчас я бы уточинил TFVC (а не TFS), VS оболчка (а не VS).
TFS (система контроля версий) это не совсем система контроля версий — это часть VS. После SVN это несколько напрягает. Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
TFVC не имеет независимого клиента командной строки, а является частью некой оболочки.
Неверно. У TFS нет автономного клиента командной строки — так верно. При этом TFVC не является частью никакой оболочки, потому что существует вообще на сервере.
Я говорю только о клиентской части.
Итого:
С точки зрения клентской части нет автономного клиента TFVC, как привыкли те, кто работает с SVN.
Кроме того, каждай VS технически устанавливает своего клиента командной строки TFVC.
И что бы я совсем все понял:
При этом может быть установлен только один клиент Power Tools для Windows Explorer.
Итого:
С точки зрения клентской части нет автономного клиента TFVC, как привыкли те, кто работает с SVN.
Кроме того, каждай VS технически устанавливает своего клиента командной строки TFVC.
И что бы я совсем все понял:
При этом может быть установлен только один клиент Power Tools для Windows Explorer.
Кроме того, каждай VS технически устанавливает своего клиента командной строки TFVC.
Насколько я помню, это не обязательно, т.е. можно поставить студию без TFS-клиента.
(отдельный вопрос, конечно, зачем у вас несколько студий на компьютере)
У разных клиентов инсталлированы разные версии продукта, которые разработаны на разных студиях.
Клиенту все равно, в какой студии разработан продукт, ему важно, на каком фреймворке он работает. Нет никакого практического смысла держать студии от 2010SP1 и выше, их все можно заменить одной.
Более того, мы в свое время прекрасно работали над одним и тем же решением в разных студиях (2010 и 2012), когда не было возможности сразу весь отдел обновить.
Более того, мы в свое время прекрасно работали над одним и тем же решением в разных студиях (2010 и 2012), когда не было возможности сразу весь отдел обновить.
клиенту конечно все равно, но нам нет.
ему поставили несколько лет назад программу, она до сих пор работает. Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран. Кроме того надо учесть, что в продукте есть и c++ проекты, что несколько затрудняет перемешивать студии. Чисто для .NET solutions многие конечно используют более продвинутую версию студии.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
ему поставили несколько лет назад программу, она до сих пор работает. Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран. Кроме того надо учесть, что в продукте есть и c++ проекты, что несколько затрудняет перемешивать студии. Чисто для .NET solutions многие конечно используют более продвинутую версию студии.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран.
Вы уверены, что «естестественно»? Вы считали сравнительную стоимость содержания зоопарка из нескольких студий vs обновить проекты под актуальную версию?
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Это тоже очень странно. TFS вообще не трогает файлы, этим занимается только и исключительно студия. Вы обнаружили несовместимость 2013 и 2012?
Иногда нужно что то маленькое подебагировать и изменить, то очень естественно делать именно в той студии, в которой продукт был собран.
Вы уверены, что «естестественно»? Вы считали сравнительную стоимость содержания зоопарка из нескольких студий vs обновить проекты под актуальную версию?
Лично я уверен, потому что цена ошибки (особенно в работающей версии) очень велика.
Кстати, я не использую VS213 для добавления проектов, потому что TFVC (не знаю какой версии) почему то меняет файла солюшина не так как VS2012.
Это тоже очень странно. TFS вообще не трогает файлы, этим занимается только и исключительно студия. Вы обнаружили несовместимость 2013 и 2012?
Я очень уверен. Не знаю кто, но кто то создает файл ".vssscc", всякие ключи (типа SccTeamFoundationServer) в файле солюшина.
Лично я уверен, потому что цена ошибки (особенно в работающей версии) очень велика.
Ошибки в работающих версиях лечатся тестированием. Поверьте, при зоопарке студий на машине шанс получить ошибку из-за того, что параллельно стоит другая версия студии, не сильно меньше, чем просто при обновлении проекта.
А с другой стороны, релиз все равно должен собираться на билд-сервере, какая вам разница, что на машине разработчика стоит? Или вы на билд-агенте тоже ставите больше одной версии тулчейна?
Не знаю кто, но кто то создает файл ".vssscc", всякие ключи (типа SccTeamFoundationServer) в файле солюшина.
Visual Studio это делает.
А с другой стороны, релиз все равно должен собираться на билд-сервере, какая вам разница, что на машине разработчика стоит? Или вы на билд-агенте тоже ставите больше одной версии тулчейна?
В идеале хотелось бы для каждой серьезной версии иметь отдельную билд машину. А пока на одной машине могут собираться разные версии, которые собираются разными студиями.
Самый простой сценарий чтот-то поломать, создать новый проект и по-умолчанию получить не ту версию фраймворка. Наверняка есть еще и другие нюансы (особенно для c++).
У меня с какой-то версии TFS встроился в шелл. Теперь можно как в tortoiseSVN зачекинить, посмотреть историю и все остальное. Также из проводника видно зачекиненые файлы и прочее.
.Net разрабы многим хороши, но большинство из них к сожалению действительно считают, что .Net MVC — это MVC, а TFS — это система контроля версий
а можно поподробней почему .NET MVC это не MVC? Ну и пример каноничного MVC
Пример каноничного mvc глубоко в прошлом. Насколько я помню, все серверные mvc-фреймворки в вебе — это model2, на самом деле.
по идее вью — это вью, никакого проброса неймспейсов и моделей внутрь не должно быть, должны быть переменные, циклы, хелперы темизации и форматирования вывода — всё, переменным вью в контроллере передаётся значение, если вью не меняется — его не трогают.
Вью на xsl, простые шаблоны без привязки моделей каноничны
Вью на xsl, простые шаблоны без привязки моделей каноничны
К сожалению, вам не удалось замаскировать намек на тупизну .NET-чиков.
У меня опыт сугубо негативный (после VSS). Так уж сложилось, что больше десяти лет сижу на Source Safe. Это не идеал, конечно, но система всем устраивает. Попытка перелезть на TFS сразу же упёрлась в то, что что Shared Files там не поддерживаются (либо через костыли), а мы их много где используем, ну и навязчивая интеграция со студией нам совершенно не нужна, так как мы в LabVIEW работаем. А лёгкого «Stand alone» клиента типа VSS Explorer и нет вовсе. Плюс VssReporter — дюже удобная утилита. В общем пока остались на VSS для локальных проектов, хотя древнее систему уж и не найти.
Ну есть еще CVS и RCS…
Как то много лет назад мы делали ветки на VSS. Не знаю как сейчас, но тогда создание ветки приводило к полному копированию файлов на диске сервера.
Так вот, мы начинали процесс в четверг вечером. Верующие члены команды после этого шли молиться, неверующие молились прямо на месте.
На следующий день самый стойкий проверял и чуть ли не ручками чинил этот новый созданный бранч. Когда весь процесс заканчивался, верующие опять шли молиться, а неверующие шли пить.
Это в TFS они «починили», но судя по вашему комментарию, сделали другие ошибки.
Так вот, мы начинали процесс в четверг вечером. Верующие члены команды после этого шли молиться, неверующие молились прямо на месте.
На следующий день самый стойкий проверял и чуть ли не ручками чинил этот новый созданный бранч. Когда весь процесс заканчивался, верующие опять шли молиться, а неверующие шли пить.
Это в TFS они «починили», но судя по вашему комментарию, сделали другие ошибки.
TFS (система контроля версий) это не совсем система контроля версий — это часть VS. После SVN это несколько напрягает. Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Это утверждение неверно. TFS — это отдельный серверный продукт, который к Visual Studio относится только тем, что входит в общий пакет. Сколько бы студий не стояло у вас на компьютере, TFS все равно стоит в другом месте (если вы, конечно, не ставили его на рабочую станцию, чего делать не стоило), и его версия определяется там, куда он поставлен. Студия — это один из возможных клиентов к TFS. Соответственно, функциональность TFS не зависит от версии установленной студии, зависит только то, что видно в UI.
В остальном же — вы привыкли к тому, как работает SVN, в TFS вам работать неудобно. Это не значит, что TFS хуже, это значит, что вам неудобно, и в нем нет того, к чему вы привыкли. А мне было неудобно работать в SVN в свое время.
Тут верно пишут: сравнивать надо с DVCS, вот тут все отличия вылезают в полный рост.
PS Впрочем, бранчинг/мержинг в TFS действительно сделан отвратно, к 2010 мы даже писали утилиту для трекинга. Но это критично только тем, кто активно пользуется бранчами, и только в определенных сценариях этого использования.
я делился опытом перехода с SVN на TFS и привел конкретный список вещей, которые после SVN смотрятся странно.
по поводу «неудобств» и «привыканий» я даже и не писал (типа того, что процесс сливания делается в разные стороны).
Могу ли использовать локальный режим в VS2010 если у меня на компьютере стоит VS2013 с его TFS?
по поводу «неудобств» и «привыканий» я даже и не писал (типа того, что процесс сливания делается в разные стороны).
Соответственно, функциональность TFS не зависит от версии установленной студии, зависит только то, что видно в UI.
Могу ли использовать локальный режим в VS2010 если у меня на компьютере стоит VS2013 с его TFS?
Могу ли использовать локальный режим в VS2010 если у меня на компьютере стоит VS2013 с его TFS?
Вы явно ошибаетесь в сценариях использования TFS в вашем проекте. Нет никакого практического смысла разворачивать сервер системы контроля версий на вашем компьютере. На клиентских компьютерах достаточно установить студию.
Вы явно ошибаетесь в сценариях использования TFS в вашем проекте. Нет никакого практического смысла разворачивать сервер системы контроля версий на вашем компьютере. На клиентских компьютерах достаточно установить студию.
я обсуждаю только клиентскую часть.
Интересно как студия ведет себя с worspace созданным другой студией (особенно если поиграться local и server режимами).
вот тут и тут немного обсуждается:
Интересно как студия ведет себя с worspace созданным другой студией (особенно если поиграться local и server режимами).
вот тут и тут немного обсуждается:
Q: Can I use the same workspace in multiple instances of Visual Studio?
A: Although Visual Studio does not block you from running multiple instances against the same workspace, this usage is not supported. Also, working this way is more likely to cause problems if you are using a local workspace.
Могу ли использовать локальный режим в VS2010 если у меня на компьютере стоит VS2013 с его TFS?
Вы можете работать с файлами в local workspace в любой студии. В студиях до 2012 вы не получите интерфейсного доступа к VCS.
Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Что значит «какой у меня стоит». Локально у вас должно быть несколько workspaces, на сервере можно посмотреть какой репозиторий «промаппен» в какую папку. Я называю workspace так, чтобы было понятно в какой студии он используется в основном — но открывать можно в любой.
После работы с локальным workspace в более старших версиях студии никогда не было проблем с более младшей.
Единственное, для чего это может быть важно — для local workspaces, но их я вообще не использую и если мне нужна локально вся история — я просто использую DCVS с самого начала…
Привык, что никакие файлы проекта не являются «read-only», поэтому (если стоит по крайней мере VS2012) пытаешься включать «local mode».
Ой, а как я привык, что файлы readonly! Сразу понимаешь какие файлы ты менял а какие нет, никуда не надо лезть. Если файл readonly, значит в него ты еще не лазил. Notepad++ при открытии таких файлов не дает их редактировать — сразу все понятно. Правой кнопкой мыши — и TFS => Check-out for edit. Работает даже если файл уже открыт в Notepad++.
Локальные репозитории — это совсем для другого, это попытка добавить DCVS, на мой взгляд тут лучше использовать тогда Git/Hg, потому что они для этого лучше заточены.
Power Tools не может принести новый бранч с сервера на компьютер, для этого все равно придется запустить студию.
PowerTools это такая надстройка над tfs.exe, поэтому он ставится в зависимости от версии VS, у меня стоит несколько версий локально.
Бранчи без проблем достаются тем же tfs.exe, какие хотите и куда хотите.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
А для чего такие ревизии помечать как «смерженные»? Для этого вполне можно сделать частичный мерж и отметить все оставшиеся ревизии лейблами, типа «not to merge in production».
замержить все эти ревизии в одну ревизию версии 2.
А зачем это нужно? При мёрже у вас в истории все-равно будет одна ревизия (на момент коммита мёржа), зато всегда можно посмотреть какие из ревизий в него вошли. Или что Вы пытаетесь достичь этим?
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Это делается так:
1) Идете в Pending Changes, делаете Shelve Changes при СНЯТОЙ галочке Preserve changes locally. У вас получается откат всех локальных изменений в Shelveset.
2) Дальше тестируете что хотите.
3) При необходимости сохранить делате снова Shelve без сохранения изменений локально.
4) Возвращаетесь к своим изменениям делая Unshelve с сервера.
Если нужно переключать ветки — вот одно из решений через командную строку: stackoverflow.com/questions/10240216/team-foundation-server-switch-between-branches
TortioseSVN имеет простой и понятный поиск (и фильтр) по истории бранча
Тут я полностью согласен. Но я никогда не пользовался этими возможностями SVN, даже на проектах с 70000 коммитов.
Опишите, пожалуйста, поподробнее сценарии где Вы их используете и как.
Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
Что значит «какой у меня стоит». Локально у вас должно быть несколько workspaces, на сервере можно посмотреть какой репозиторий «промаппен» в какую папку. Я называю workspace так, чтобы было понятно в какой студии он используется в основном — но открывать можно в любой.
После работы с локальным workspace в более старших версиях студии никогда не было проблем с более младшей.
Единственное, для чего это может быть важно — для local workspaces, но их я вообще не использую и если мне нужна локально вся история — я просто использую DCVS с самого начала…
Я имею ввиду, что у меня на компюьтере в папке каждой студии стоит tfs.exe и Power tools (интеграция с Windows Explorer) тоже привязана к студии. После SVN это несколько напрягает: как писать скрипт? какой TFS.exe вызывать?
Привык, что никакие файлы проекта не являются «read-only», поэтому (если стоит по крайней мере VS2012) пытаешься включать «local mode».
Ой, а как я привык, что файлы readonly! Сразу понимаешь какие файлы ты менял а какие нет, никуда не надо лезть. Если файл readonly, значит в него ты еще не лазил. Notepad++ при открытии таких файлов не дает их редактировать — сразу все понятно. Правой кнопкой мыши — и TFS => Check-out for edit. Работает даже если файл уже открыт в Notepad++.
Локальные репозитории — это совсем для другого, это попытка добавить DCVS, на мой взгляд тут лучше использовать тогда Git/Hg, потому что они для этого лучше заточены.
Cо второй частью я согласен: TFS плохо поддерживает локальный режим, что после перехода с SVN удручает.
А «read-only» все-таки требует больше телодвижений (на мой взгяд не оправданных).
PowerTools это такая надстройка над tfs.exe, поэтому он ставится в зависимости от версии VS, у меня стоит несколько версий локально.
Бранчи без проблем достаются тем же tfs.exe, какие хотите и куда хотите.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
Все-таки получить новую ветки на локальный диск через юзер интерфейс Tortoise быстрее чем открывать студию или веб-интерфейс+командная строка.
Довольно часто некие ревизии не надо сливать из версии 1 в версию 2.
А для чего такие ревизии помечать как «смерженные»? Для этого вполне можно сделать частичный мерж и отметить все оставшиеся ревизии лейблами, типа «not to merge in production».
Нам хочется отслеживать какие ревизии уже перенесли из одной версии в другую, а какие еще нет.
Tortoise позволяет легко это видеть. Ревизии которые не надо переносить мешают (они показаны как не замерженные, но их и не надо мержить).
Поэтому мы их помечаем как «смерженные».
замержить все эти ревизии в одну ревизию версии 2.
А зачем это нужно? При мёрже у вас в истории все-равно будет одна ревизия (на момент коммита мёржа), зато всегда можно посмотреть какие из ревизий в него вошли. Или что Вы пытаетесь достичь этим?
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Я предпочитаю, чтобы каждый программист переносил свои изменения из одной версии в другую сам. Кроме всего прочего его имя сохраняется в простой истории. Если какой та баг занял несколько ревизий в одной версии, хотелось бы чтобы все эти ревизии зашли как одна в новую ветку.
TFS этот сценарий не поддерживает, что после перехода с SVN напрягает.
Другой сценарий, когда нужно сразу много ревизий пометить как замерженные.
Третий сценарий когда надо откатить несколько ревизий на локальном диске. Этот сценарий я вообще не смог внятно реализовать.
Я привык создавать бранчи для любых вещей, которые потребуют какого то времени или проверок на тестовой машине.
Это делается так:
1) Идете в Pending Changes, делаете Shelve Changes при СНЯТОЙ галочке Preserve changes locally. У вас получается откат всех локальных изменений в Shelveset.
2) Дальше тестируете что хотите.
3) При необходимости сохранить делате снова Shelve без сохранения изменений локально.
4) Возвращаетесь к своим изменениям делая Unshelve с сервера.
Shelve вещь хорошая и полезная. И для некоторых сценариев работает хорошо.
Но мы используем бранчи для «длительной» разработки, что подразумевает много коммитов, тестирования бранча на тестовом компьютере и строительства билда на билд-машине. Я так понимаю, что данные сценарии shelve не поддерживает.
TortioseSVN имеет простой и понятный поиск (и фильтр) по истории бранча
Тут я полностью согласен. Но я никогда не пользовался этими возможностями SVN, даже на проектах с 70000 коммитов.
Опишите, пожалуйста, поподробнее сценарии где Вы их используете и как.
Примеры:
— найти по имени человека и слову из названия фичи/бага (мы коммитим с полным названием фичи/бага).
— найти все коммиты нескольких людей (какой-то определенной команды).
— найти специальные ревизии (мы коммитим после количество падающих тестов и номера билдов).
— найти коммиты по какому-то слову.
Я так и не нашел поиск в Power Tools.
Так получилось, что на двух последних местах работы первым, что я делал, это был перевод большого объема кода с SVN и подобной внутренней системы на TFS. Большинство проблем возникало у людей, кто работал со старой системой 5-10-15 лет и не мог быстро адаптироваться к новой. Я же очень люблю TFS за следующие его возможности:
1) Shelvesets. Мы используем их везде. Не надо больше никаких diff, просто готовишь нужный тебе набор изменений и он доступен любому из твоей команды. Нужно ревью — готовишь Shelveset. Предлагаешь изменения в проект без коммита — делаешь Shelveset. и так далее.
2) Текст коммитов меняется стандартно из окошка истории. Просто открываешь нужный тебе changeset, и можно сделать любое изменение в тексте. Часто бывает полезно, когда закоммитил что-то а не описал в изменении.
3) Баг, если его выбрать и отметить как Resolve, сам закрывается в системе. Очень удобно, не нужно лезть за тикетом. И сам тикет не нужно вписывать…
4) Readonly все, что ты не менял. Всегда знаешь, что уже редактировалось, а что — нет.
5) Alert on change настраивается просто одним кликом в студии. Никаких больше хуков для этого!!!
6) Есть RESTful API для программного создания бага просто одним GET-реквестом (есть и POST), что очень облегчает интеграцию в другие продукты с возможностью быстрого создания бага из твоего приложения.
Есть еще пара мелочей (например быстрое открытие просмотра и сравнения из истории и пр.), но тут дело уже скорее в юзабилити, чем в самой системе как таковой…
1) Shelvesets. Мы используем их везде. Не надо больше никаких diff, просто готовишь нужный тебе набор изменений и он доступен любому из твоей команды. Нужно ревью — готовишь Shelveset. Предлагаешь изменения в проект без коммита — делаешь Shelveset. и так далее.
2) Текст коммитов меняется стандартно из окошка истории. Просто открываешь нужный тебе changeset, и можно сделать любое изменение в тексте. Часто бывает полезно, когда закоммитил что-то а не описал в изменении.
3) Баг, если его выбрать и отметить как Resolve, сам закрывается в системе. Очень удобно, не нужно лезть за тикетом. И сам тикет не нужно вписывать…
4) Readonly все, что ты не менял. Всегда знаешь, что уже редактировалось, а что — нет.
5) Alert on change настраивается просто одним кликом в студии. Никаких больше хуков для этого!!!
6) Есть RESTful API для программного создания бага просто одним GET-реквестом (есть и POST), что очень облегчает интеграцию в другие продукты с возможностью быстрого создания бага из твоего приложения.
Есть еще пара мелочей (например быстрое открытие просмотра и сравнения из истории и пр.), но тут дело уже скорее в юзабилити, чем в самой системе как таковой…
Прежде всего, хотел бы поблагодаривать вас за ответы. Вы один из немногих, которые отвечают аргументами.
Я сам встроил в продукт открытие бага прямо в TFS с заливанием нужной информации. Это действительно хорошая вещь. Кроме того написал утилиту, которая по номеру бага складывает все присоединенные файлы в нужно мне место. Но это все-таки не совсем контроль версий.
Кстати, SVN позволяет менять не только комментарии к ревизии, но и имя автора, чего я не нашел в TFS.
Я сам встроил в продукт открытие бага прямо в TFS с заливанием нужной информации. Это действительно хорошая вещь. Кроме того написал утилиту, которая по номеру бага складывает все присоединенные файлы в нужно мне место. Но это все-таки не совсем контроль версий.
Кстати, SVN позволяет менять не только комментарии к ревизии, но и имя автора, чего я не нашел в TFS.
Shelvesets. Мы используем их везде. Не надо больше никаких diff, просто готовишь нужный тебе набор изменений и он доступен любому из твоей команды. Нужно ревью — готовишь Shelveset. Предлагаешь изменения в проект без коммита — делаешь Shelveset. и так далее.Как по мне — так довольно кустарная замена форкам (или веткам) и мердж-реквестам.
Я пользовался TFS достаточно долго. По вашим любимым возможностям:
> 1) Shelvesets.… Нужно ревью — готовишь Shelveset.
Расскажите мне как вы делаете итерации в code review?
> 4) Readonly все, что ты не менял.
Не нужно делать все readonly чтобы понять, что менял или нет. Расскажите, как вы работаете в offline mode?
Все остальные пункты — они так же есть и в других продуктах, так что не понимаю, какие тут именно прелести.
> 1) Shelvesets.… Нужно ревью — готовишь Shelveset.
Расскажите мне как вы делаете итерации в code review?
> 4) Readonly все, что ты не менял.
Не нужно делать все readonly чтобы понять, что менял или нет. Расскажите, как вы работаете в offline mode?
Все остальные пункты — они так же есть и в других продуктах, так что не понимаю, какие тут именно прелести.
Как я не люблю TFS, но всё же. Нет такой системы контроля версий как TFS, есть TFVC (Team Foundation Version Control). И студия умеет с ним работать, а не он является её частью. Также с ним умеет работать Eclipse www.microsoft.com/en-us/download/details.aspx?id=30661 Но это вырывает мозг от осознания того что автор не понимает о чём говорит
В остальном нужно понять что Team Foundation Server это комплексный продукт включающий систему контроля версий (git, tfvc), отчёты, систему управления требования, систему управления дефектами, систему управления тестовой документацией, систему непрерывной интеграции. Всё это связанно, но часто уступает аналогам.
TFS (система контроля версий) это не совсем система контроля версий — это часть VS. После SVN это несколько напрягает. Если у меня стоит 3 студии, то чтобы понять какой TFS у меня стоит и работает требуются дополнительные усилия.
В остальном нужно понять что Team Foundation Server это комплексный продукт включающий систему контроля версий (git, tfvc), отчёты, систему управления требования, систему управления дефектами, систему управления тестовой документацией, систему непрерывной интеграции. Всё это связанно, но часто уступает аналогам.
Но это вырывает мозг от осознания того что автор не понимает о чём говорит
Да, я много чего не понимаю в TFVC. Один из спосовоб что то понять, это написать пост, почитать комментарии и обсудить их с теми кто понимает.
Я не понимаю например, почему TFS.exe находится в папке каждой студии. Как скрипты писать? Студию сегодня используешь одну, завтра другую. Мне бы TFVC командую строку, которая стоит сама по себе.
Помогите понять автору.
Категорически приветствую!
Общие впечатления от статьи — вы начали использовать инструмент даже не удосужившись ознакомиться с – скажем так – «теорией» его использования.
Впечатление такое, что вы пытаетесь использовать TFS так же, как до этого использовали SVN. Это видно и по используемой терминологии, и по «ходу мысли».
Соответственно, общий совет разберитесь хотя бы с понятиями workspace и changeset (все есть в MSDN). Там же можно ознакомиться с идеологией ветвления и слияния принятой в TFS. Многие вопросы отпадут сами собой.
Перед тем как, как давать какие-либо рекомендации по описанным вами ситуациям, прошу:
1. Пояснить (хотя бы на «пальцах»), что вы понимаете под «ревизией». Судя по сложностям, которые вы испытываете – это не changeset.
2. Показать использующийся Branch plan. Это нужно для того, чтобы более предметно давать рекомендации.
Общие впечатления от статьи — вы начали использовать инструмент даже не удосужившись ознакомиться с – скажем так – «теорией» его использования.
Впечатление такое, что вы пытаетесь использовать TFS так же, как до этого использовали SVN. Это видно и по используемой терминологии, и по «ходу мысли».
Соответственно, общий совет разберитесь хотя бы с понятиями workspace и changeset (все есть в MSDN). Там же можно ознакомиться с идеологией ветвления и слияния принятой в TFS. Многие вопросы отпадут сами собой.
Перед тем как, как давать какие-либо рекомендации по описанным вами ситуациям, прошу:
1. Пояснить (хотя бы на «пальцах»), что вы понимаете под «ревизией». Судя по сложностям, которые вы испытываете – это не changeset.
2. Показать использующийся Branch plan. Это нужно для того, чтобы более предметно давать рекомендации.
Я как всегда почти согласен «я не понимаю этот инструмент и его неизвестную мне теорию».
Почитал я про changeset:
И как мне это помогает? Чем он отличается от ревизии? Наличием привязки к work-items? Так это не принципиально для данного поста.
Вот так определяют ревизию:
Почитал я про changeset:
When you check in code into TFS, a changeset is created. A changeset is a set of files and work items associated together a time of check in. If you don't associate work items with the code, the changeset will just consist of just the set of files. The heart of this is due to the fact that the check-in process is an atomic transaction. When you perform a check in, the process tells TFS how many files and work items are going to be checked in. Assuming all the files get transferred properly into TFS, TFS will generate a changeset number. This number can be used to trace back what code files and work items were worked on.
И как мне это помогает? Чем он отличается от ревизии? Наличием привязки к work-items? Так это не принципиально для данного поста.
Вот так определяют ревизию:
A Subversion client commits (that is, communicates the changes made to) any number of files and directories as a single atomic transaction. By atomic transaction, we mean simply this: either all of the changes are accepted into the repository, or none of them is. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number assigned to the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory.
Фундаментальное отличие чейнджсета от ревизии состоит в том, что ревизия — это состояние всего дерева; чейнджсет же — это конкретный набор изменений, который был создан в рамках чекина.
Давайте тогда по порядку.
Начнем с «как будто ее замержили».
Есть ветвь «версия 1» – условный main. Есть ветвь «версия 2» от main – условный dev. В main нашли баг, и для его исправления создали ветвь «Bug1 Fix». Так? Предположим, что так… По прошествии какого-то времени, в ветви «Bug1 Fix» работа заканчивается (баг повержен – все дела), и мы «вливаем» ветвь «Bug1 Fix» в main. Результатом этой операции будет _один конкретный_ changeset.
Пожалуйста поясните, о каких «неких _ревизиях_», которые «и не надо сливать» в этом случае идет речь?
Начнем с «как будто ее замержили».
Есть ветвь «версия 1» – условный main. Есть ветвь «версия 2» от main – условный dev. В main нашли баг, и для его исправления создали ветвь «Bug1 Fix». Так? Предположим, что так… По прошествии какого-то времени, в ветви «Bug1 Fix» работа заканчивается (баг повержен – все дела), и мы «вливаем» ветвь «Bug1 Fix» в main. Результатом этой операции будет _один конкретный_ changeset.
Пожалуйста поясните, о каких «неких _ревизиях_», которые «и не надо сливать» в этом случае идет речь?
Все таки «версия 1 „- это версия 1 продукта, а “версия 2» — это следующая версия продукта (это не совсем mail и dev).
Если продолжить ваш сценарий, то может быть этот баг уже был починен (или не актуален) в версии 2 (dev — как вы его назвали), в этом случае нет необходимости переносить ветвь (так правильно?) из версии 1 в версию 2.
Если продолжить ваш сценарий, то может быть этот баг уже был починен (или не актуален) в версии 2 (dev — как вы его назвали), в этом случае нет необходимости переносить ветвь (так правильно?) из версии 1 в версию 2.
Все таки «версия 1 „- это версия 1 продукта, а “версия 2» — это следующая версия продукта (это не совсем mail и dev).
Поэтому и «условный» main/dev.
Если продолжить ваш сценарий, то может быть этот баг уже был починен (или не актуален) в версии 2 (dev — как вы его назвали), в этом случае нет необходимости переносить ветвь (так правильно?) из версии 1 в версию 2.
Только не _ветвь_, а именно changeset (набор изменений… но, это долго выговаривать :-)).
Чисто теоритически, если баг в dev был уже пофиксен, то можно было просто «спустить» необходимые изменения (конкретные changeset'ы) из dev в main. Ветвь «Bug1 Fix» в этом случае нужна только если способ исправления который был использован в dev уже к main не подойдет. «Вливать» «Bug1 Fix» в main в этом случае все равно придется, но переносить получившийся changeset в dev смысла уже может и не быть.
P.S. С этим уже ознакомились?
Чисто теоритически, если баг в dev был уже пофиксен, то можно было просто «спустить» необходимые изменения (конкретные changeset'ы) из dev в main.
Когда это возможно, то конечно. Но не всегда это можно сделать: если баг починен как часть redesign, то ествественно мы не хотим весь redesign переносить в продакшн версию: правильнее просто починить баг.
Иногда в продакшн делается заплатка, которая не переносится, а проблема решается более общим подходом.
P.S. С этим уже ознакомились?
Еще нет, но линк уже открыл.
Спасибо.
С этим уже ознакомились?Если меня что-то и удивляет в «мире» TFS, так это упомянутый монументальный труд. Почему-то гораздо более всеобъемлющий Git Flow (или вообще Driessen Workflow) можно описать на одной стороне листа A4, а вот в TFS приходится книги сочинять.
Я понимаю, что речь идет о TFS, но в комментариях столько раз прозвучало SVN\Git, что не могу не добавить свои 5 копеек.
Сначала работали на Svn (клиент TortoiseSvn), большие проекты, много разработчиков, каждая фича — в отдельной ветке (т.е. веток и мержей много). Хорошая интеграция с Jira (вкладка, где можно посмотреть коммиты, если чел забыл проставить метку с названием ветки). За несколько лет проблем не было. Ясно дело, что раз в год и незаряженное ружье стреляет, т.е. были случаи тяжелых мержей — но редко, и не идет ни в какое сравнение с тем, что началось потом…
А что потом? Потом настал момент моды на Git. Все стали переходить на Git (я имею ввиду другие команды в компании), при этом в личной беседе никто не мог аргументировать «зачем?». Ну типа это модно, Git крут, все на него уходят (это было год назад). Мы тоже перешли. Идеология Git'а другая, многое было неочевидно и непривычно. Потом мы начали делать все merg'и через rebase, чтобы при вливании ветки видеть все комиты по фиче рядышком (в логе). Каждый rebase — это новый седой волос, поскольку при нем идет протаскивание новых комитов через все старые коммиты от корня ветки, т.е. разрешать много конфликтов приходилось. Иногда merge был просто адским, и хотя Git вроде как лучше под это заточен, с Svn таких проблем никогда не было. Иногда мы теряли коммиты при кривом автомерже, приходилось руками доставать из lostHeads. В общем, это далеко не все беды, начавшиеся с Git. А польза? Никакой, абсолютно. То, что это распределенная система контроля версий — в моей работе скорее мешает, мне эта фича не нужна. По субъективным ощущением merge в Git работает ничуть не лучше. Телодвижений для простых операций приходится делать больше. Работать напрямую с репозиторием, например, без переключения на ветку скачать файл из какой-то ревизии Git не умеет. Stash штука гораздо менее удобная, чем patch, очень часто он не прикладывается. Работать стало труднее, назад на Svn проекты перевозить никто не будет, но поклонники Git'а могут снисходительно говорить «вы просто не умеете его готовить». Буду признателен за примеры того, чем Git лучше, не в open-source, а в больших коммерческих проектах.
Сначала работали на Svn (клиент TortoiseSvn), большие проекты, много разработчиков, каждая фича — в отдельной ветке (т.е. веток и мержей много). Хорошая интеграция с Jira (вкладка, где можно посмотреть коммиты, если чел забыл проставить метку с названием ветки). За несколько лет проблем не было. Ясно дело, что раз в год и незаряженное ружье стреляет, т.е. были случаи тяжелых мержей — но редко, и не идет ни в какое сравнение с тем, что началось потом…
А что потом? Потом настал момент моды на Git. Все стали переходить на Git (я имею ввиду другие команды в компании), при этом в личной беседе никто не мог аргументировать «зачем?». Ну типа это модно, Git крут, все на него уходят (это было год назад). Мы тоже перешли. Идеология Git'а другая, многое было неочевидно и непривычно. Потом мы начали делать все merg'и через rebase, чтобы при вливании ветки видеть все комиты по фиче рядышком (в логе). Каждый rebase — это новый седой волос, поскольку при нем идет протаскивание новых комитов через все старые коммиты от корня ветки, т.е. разрешать много конфликтов приходилось. Иногда merge был просто адским, и хотя Git вроде как лучше под это заточен, с Svn таких проблем никогда не было. Иногда мы теряли коммиты при кривом автомерже, приходилось руками доставать из lostHeads. В общем, это далеко не все беды, начавшиеся с Git. А польза? Никакой, абсолютно. То, что это распределенная система контроля версий — в моей работе скорее мешает, мне эта фича не нужна. По субъективным ощущением merge в Git работает ничуть не лучше. Телодвижений для простых операций приходится делать больше. Работать напрямую с репозиторием, например, без переключения на ветку скачать файл из какой-то ревизии Git не умеет. Stash штука гораздо менее удобная, чем patch, очень часто он не прикладывается. Работать стало труднее, назад на Svn проекты перевозить никто не будет, но поклонники Git'а могут снисходительно говорить «вы просто не умеете его готовить». Буду признателен за примеры того, чем Git лучше, не в open-source, а в больших коммерческих проектах.
Во люди… Ну и чему вы удивляетесь?!
По теме скажу так.
Рядом сидят ребята, которые до этого больше трех лет сидели на SVN (а некоторые и дольше). В прошлом году пересадили их на Git. Да, пришлось прочитать лекции на тему «как делать не надо». Да, пришлось «бить по рукам», когда пытались делать не «как надо», а «как привыкли». Да, по первости словили пару раз non-fast-forward на пуше, и пришлось помогать и объяснять что, как и почему. Но это все в течении недели. Зато теперь ребята чуть не урчат от удовольствия, и фиг их на SVN опять заманишь (ща спецом пообщался за это :-)). И таки да, это «большой коммерческий проект».
Делать все merg'и через rebase, чтобы при вливании ветки видеть все комиты по фиче рядышком (в логе)и стонать за то, как все плохо :-) Это в системе где 90% слияний — «перемотка». Таки «вы просто не умеете его готовить» (с).
По теме скажу так.
Рядом сидят ребята, которые до этого больше трех лет сидели на SVN (а некоторые и дольше). В прошлом году пересадили их на Git. Да, пришлось прочитать лекции на тему «как делать не надо». Да, пришлось «бить по рукам», когда пытались делать не «как надо», а «как привыкли». Да, по первости словили пару раз non-fast-forward на пуше, и пришлось помогать и объяснять что, как и почему. Но это все в течении недели. Зато теперь ребята чуть не урчат от удовольствия, и фиг их на SVN опять заманишь (ща спецом пообщался за это :-)). И таки да, это «большой коммерческий проект».
Rebase не от хорошей жизни же. После вливания ветки я обычно в логе смотрю комиты, на всякий случай, без rebase — они разбросаны по логу. Но это ладно. Кроме как «урчание от счастья» что можете сказать?) Конкретно, в чем неудобство\ограниченность функционала\недостаток SVN, которого нет в Git? В чем конкретно профит от перехода на Git, кроме чисто религиозного «Git — это круто»?
Rebase не от хорошей жизни жеMercurial, например?
С ним не работал, у нас ни в одной команде не используется, вряд ли на него будем переходить. Вопрос-то не «какую бы еще СКВ попробовать», а «так чем же Git настолько лучше SVN?»
В данном конкретном случае вы наткнулись на самую большую слабость Гита: невозможность отслеживать lineage без введения административных мер типа ребэйза, сквоша и комментариев вида «Merged branch foo/barbaz».
Rebase не от хорошей жизни же. После вливания ветки я обычно в логе смотрю комиты, на всякий случай, без rebase — они разбросаны по логу.
:-) Не… я вполне допускаю, что может быть «так надо». Но, емнип, даже git log умеет группировать комиты по веткам. Если серьезно, можете описать свой workflow? Как фича-бранч делается и т.п.?
По остальному — именно активное использование [различных] стратегий ветвления/слияния (особенно последнее) есть основная (если не единственная) причина перехода с SVN (и т.п.) на Git/TFVC/Merc. Это сугубое, имхо.
У нас стратегия очень простая: есть master (релизы), dev (мелкие правки), и на каждую фичу заводится отдельная ветка. Как правило от dev. Фича закончилась — вливается в dev, как правило даже не руками, а через GitFlow. Мерж везде настроен через rebase, это не мое решение, но вроде как народ, пришедший к такой схеме, долго копал тему, ломал копья, в итоге вот так. Мне нравится тем, что в логе я вижу все коммиты по фиче рядышком, где ветка вливается в dev (а не разбросанными по логу).
Картинка вроде бы простая, проблемы начинаются когда процесс хоть чуточку усложняется, как оно на деле бывает, например:
1. Например, долгая разработка фичи. Понятно, чтобы сильно не разъехаться, надо периодически делать integrate to develop. Но веток много, штук 10, разработчика на проекте 3, где-то чуть затянули, в дев влилось что-то мощное — все, адский rebase ветки обеспечен.
2. Бывали потери коммитов. Помню такой пример: есть код в деве, который в ветке был удален, ветку влили. А в другой ветке (от дева) что-то завязано на этот код. При rebase ветки Git'у почему-то снесло крышу, он автоматом потерял часть коммитов.
3. Напрягает идеология Git'а «все в одной папке». Бывает, что мне быстро нужно бросить основную задачу, переключиться на другую ветку, потом еще на одну, потом обратно. В SVN у меня каждая фича лежала в отдельной папке на диске, т.е. я легко мог бросить разломанный код, просто открыть в студии другой проект. Здесь приходится делать финты ушами для переключения ветки: либо stash (который потом может не встать, если что-то в ветке изменилось), либо локальный коммит (который для разломанного кода делать не хочется).
Картинка вроде бы простая, проблемы начинаются когда процесс хоть чуточку усложняется, как оно на деле бывает, например:
1. Например, долгая разработка фичи. Понятно, чтобы сильно не разъехаться, надо периодически делать integrate to develop. Но веток много, штук 10, разработчика на проекте 3, где-то чуть затянули, в дев влилось что-то мощное — все, адский rebase ветки обеспечен.
2. Бывали потери коммитов. Помню такой пример: есть код в деве, который в ветке был удален, ветку влили. А в другой ветке (от дева) что-то завязано на этот код. При rebase ветки Git'у почему-то снесло крышу, он автоматом потерял часть коммитов.
3. Напрягает идеология Git'а «все в одной папке». Бывает, что мне быстро нужно бросить основную задачу, переключиться на другую ветку, потом еще на одну, потом обратно. В SVN у меня каждая фича лежала в отдельной папке на диске, т.е. я легко мог бросить разломанный код, просто открыть в студии другой проект. Здесь приходится делать финты ушами для переключения ветки: либо stash (который потом может не встать, если что-то в ветке изменилось), либо локальный коммит (который для разломанного кода делать не хочется).
По поводу (3) — можно же склонировать с самого себя же и будет два репозитория рядом.
Ну так-то да… Но вообще хотелось бы жить по «Фэн-Шую»: переходя на определенный стек технологий следовать принятым там best practice, которые выросли на опыте проб и ошибок людей. Git'оводы обычно против нескольких папок, там вроде бы так не принято, т.е. выбирая систему контроля версий мы «должны» не просто поменять софт, но и идеологию разработки: короткие атомарные коммиты на каждый чих, что дает возможность чуть ли не всегда переключиться на другую ветку.
Хорошо, попробуем «на пальцах» :-)
Для начала без центрального репозитория. Имеем ветвь dev и, например, ветвь bug_fix от dev. Работаем мы в bug_fix. Баг пофиксили. Надо этот фикc «влить» в ветвь dev.
1. Можно это сделать так:
Вполне нормальный вариант, в dev можем получить доп. комит на слияние.
2. Можно это сделать так:
История будет линейной. «Лишнего» комита нет. Но, за такие шутки — как говорится — в зубах бывают промежутки.
3. Можно это сделать так:
Такой вариант, насколько я в этом разбираюсь, должны бы использовать вы. История будет линейная, а при слиянии гарантированно будет просто «перемотка». Получить доп. комит на слияние можно только сознательно использовав no-ff.
Вы как делаете?
Для начала без центрального репозитория. Имеем ветвь dev и, например, ветвь bug_fix от dev. Работаем мы в bug_fix. Баг пофиксили. Надо этот фикc «влить» в ветвь dev.
1. Можно это сделать так:
$git checkout dev$git merge bug_fixВполне нормальный вариант, в dev можем получить доп. комит на слияние.
2. Можно это сделать так:
$git checkout dev$git rebase bug_fixИстория будет линейной. «Лишнего» комита нет. Но, за такие шутки — как говорится — в зубах бывают промежутки.
3. Можно это сделать так:
$git checkout bug_fix$git rebase dev$git checkout dev$git merge bug_fixТакой вариант, насколько я в этом разбираюсь, должны бы использовать вы. История будет линейная, а при слиянии гарантированно будет просто «перемотка». Получить доп. комит на слияние можно только сознательно использовав no-ff.
Вы как делаете?
Господа, я все понимаю: новая философия, свои понятия, но как мне сделать то, что в SVN называется Export?
Мне надо просто получить исходники проектика на своем диске без всяких привязок к контролю версий?
Мне надо просто получить исходники проектика на своем диске без всяких привязок к контролю версий?
Физически скопировать, открыть в студии, сказать Change source control — Unbind.
Пункт «физически скопировать» можно заменить на Download в Web-интерфейсе.
Пункт «физически скопировать» можно заменить на Download в Web-интерфейсе.
Я дико извиняюсь, а на кой? Что вы с этими исходниками делать-то потом собираетесь?!
Вот чесслово — просто интересно. Единственное что мне к вечеру приходит на ум — это эдакий извращенный вариант deploy.
Ну и да… по способу вам уже ответили.
Вот чесслово — просто интересно. Единственное что мне к вечеру приходит на ум — это эдакий извращенный вариант deploy.
Ну и да… по способу вам уже ответили.
Я дико извиняюсь, а на кой? Что вы с этими исходниками делать-то потом собираетесь?!
Так я просто хотел посмотреть код утилитки.
Хотя может пригодиться и для запуска тестов.
Ну и да… по способу вам уже ответили.
ну да. А чего TFS команда так не любит PowerTools?
Вы бы предпочли, чтобы команда TFS тратила время на доработку PowerTools, или на более адекватную поддержку бранчей?
Сегодня опять проявились интересные особенности мержа: у нас тут бегает утилика, которая посылает отчет с набором changesets, которые не были замержены между Main двух версий (смотрите код ниже).
Вчера она прислала «пустой» отчет. А после добавления одного changeset, она прислала отчет с 4 не замерженными changesets, причем 3 из которых месячной давности. На всякий случай добавлю, что это происходит не первый раз.
Вчера она прислала «пустой» отчет. А после добавления одного changeset, она прислала отчет с 4 не замерженными changesets, причем 3 из которых месячной давности. На всякий случай добавлю, что это происходит не первый раз.
TfsTeamProjectCollection tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://address"));
VersionControlServer versionControl = tfs.GetService<VersionControlServer>();
return versionControl.GetMergeCandidates(fromBranch, toBranch, RecursionType.Full);
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт использования TFS после перехода с SVN