Pull to refresh

Comments 32

Как насчет миграции из собственного версионника tfs в git с сохранением истории?
кстати, зачем тогда делали тулзу git-tf, практически повторяющую git-tfs, чтобы через полгода включить git в tfs нативно?
Чтоб народу легче жилось. Я за git-tf благодарен сердечно.
Если не секрет, как это реализовано на стороне Visual Studio? По последней информации, git как библиотека отсутствовал, велись работы по libgit2 — но состояние проекта было противозачаточное. Visual Studio скачивает локально бинарник git и вызывает его / парсит вывод? Или собственная имплементация протокола?
Неужто Вы не верите, что Майкрософт свою реализацию протокола написала?
Мне абсолютно все равно какую реализацию они выбрали. Мне это интересно ради лучшего понимания текущей деспозиции в технологиях.
Никто ничего не парсит. Человек 5 из MS помогали делать libgit2 libgit2.github.com/ там появилось много фич.
То есть допилили libgit2? Позитивно.
UFO just landed and posted this here
Я имел ввиду, что еще пару дней назад он был совсем другой
Там целая команда из MS перешла на работу в Github где усердно допиливала libgit2 и прочие делала прочие контриьбшны в апстрим гита.

У Хансельмана больше деталей.
Да, mercurial было бы приятно увидеть. Но чем дальше, тем боле гита везде и всюду и поддержкой mercurial в своих продуктах уже мало кто хочет заморачиваться.
Вот и интересно узнат как на это смотрят специалисты из микрософта. Лишняя гирька на чашку весов.
Я не могу озвучивать планы DevDiv. Но работа по унификации интерфейса vsix с различными системами контроля версий проделана очень большая.

P.S. Кое где mercurial будет пологичнее Git.
Хорошо, я так клиентам и передам — «планы скрывают» :).
Наконец-то, новые, нескучные обои!

image
Это всё интересно, однако
Team Foundation Server – Our plan is to include Git support in the next major release of TFS. No date has yet been announced.

Очень хочется локального сервера =(
Вот сделали бы ещё веб-интерфейс, который не тормозит и живёт независимо от монструозного SharePoint'а. Почему-то формочки создания и просмотра WorkItem'ов в Visual Studio раздражают…
На SharePoint сделана небольшая часть работы с документами и отчетами. В остальном веб-интерфейс TFS никак с SharePoint не связан и никаких компонент от него не использует.
— Ну, например, как быстро (и не в IE) посмотреть список work Items по заданному критерию (запрос, например)?

— Как открыть несколько задач в разных табах, а не во всплывающих окошках?

— Как управлять видимостью Query через Web (Team Query vs. My Query)?

Ну и ещё, наверное, самый, наверное, раздражающий для меня сейчас фактор: как применить действие ко всем Work Items в списке (они могут быть разных типов). Например, махом перекинуть из одной итерации в другую или назначить на одного разработчика. Да, знаю про Work Item Templates, но создавать отдельный template для каждого типа Work Item'а каждый раз, когда я хочу скинуть «остатки по итерации» на следующую — ИМХО перебор.
Задачи которые вы описываете легче и эффективнее делать в team explorer. Для групповых операций используйте плагин для Excel.
Спасибо, в общем-то — так и делаю. Но вопрос был изначально — что не устраивает в веб-интерфейсе. Ну, и вообще, чисто субъективно, немного странно, что мне нужен Excel и Visual Studio для нормальной работы с TFS.

Особенно, если сделать вид, что я «просто менеджер» и мне Visual Studio в ежедневных задачах… хм… не особенно требуется, а надо отслеживать лишь прогресс работы и управлять объёмом задач в итерации.
А можно интегрировать Team Foundation Service с github как таковым?
Работает ли Code Review из стандартного скрамовского шаблона?
Например с помощью github.com/git-tfs/git-tfs
это гейт двухсторонний.
Неее, я не про это.

Пусть у меня есть гитовский (не TFVC!) репозиторий в Team Foundation Service (https://tfs.visualstudio.com/). Я хочу использовать его функциональность по управлению тасками, но при этом хочется прозрачно отзеркалить релизную, например, ветку на гитхаб в открытый доступ.
DVCS на то и DVCS потому что там такие сценарии реализуются в две команды. Это совершенно стандартный сценарий.
Эти две команды кто-то должен запустить. Со стороны гитхаба можно настроить хук, который заберет изменения из другого репозитория. Но кто-то же должен дернуть за этот хук в момент коммита?
Вопрос несколько странный в контексте Git. Вы можете свои репы клонировать куда угодно, хоть в гитхаб хоть на луну. Лить туда код, мержиться с изменениями в обратную сторону. В этом суть идеологии Git. Насчет Code Review не уверен на 100%, не проверял но думаю что работает.
Sign up to leave a comment.