SVN проти Team Foundation Server [закрито]

Кілька місяців тому моя команда переклала наш контроль над джерелами на Apache Subversion з Visual SourceSafe , і ми не були щасливішими.

Нещодавно я дивився на Team Foundation Server , і принаймні на перший погляд, це здається дуже вражаючим. Існує чудова інтеграція з Visual Studio та безліч чудових інструментів для баз даних, тестерів, менеджерів проектів тощо.

Найбільш очевидна різниця між цими двома продуктами - ціна. Важко перемогти Subversion Apache (безкоштовно). Командний сервер Team є досить дорогим, тому додаткові функції дійсно повинні були б загнати Subversion у штани.

• Хтось має практичний досвід роботи з обома?
• Як вони порівнюють?
• Чи насправді Team Foundation Server коштує витрат?

Нещодавно я приєднався до проекту з відкритим кодом у CodePlex. Вони використовують TFS для контролю джерел, і я повинен сказати, що це абсолютно чудово. Поки що я неймовірно вражений цим. Я шанувальник інтеграції IDE та того, як легко розгалужувати та мітити код. Додавання рішення для керування джерелом - це приблизно два кліки, якщо ви вже все налаштували належним чином.

Зараз. Чи варто це вагомого цінника? Я не думаю. Вигода від роботи над проектами в CodePlex полягає в тому, що це дозволяє мені отримати досвід роботи з TFS, який мені потрібен, у випадку, якщо мені доведеться десь пізніше використовувати його. Якщо вам потрібна хороша інтеграція IDE для вашого Source Control, скористайтеся пакетом інтеграції VisualSVN . Отримати багато таких самих функцій (безкоштовно на недоменних комп’ютерах до речі) - це набагато дешевша інвестиція.

Ось найбільші відмінності між ними для мене, і я використовував обидва:

1) TFS досить тісно пов'язаний із "способом Visual Studio" розвитку. Це не означає, що TFS тісно пов'язаний з IDE VS, це означає, що TFS намагається зберегти звичну парадигму "перевірка" / "перевірка" Visual SourceSafe, навіть коли це вже не є відповідною моделлю. Концепція Subversion "зафіксувати" / "оновити" набагато реалістичніша, якщо у вас є розробники, які можуть проводити час відключеним від мережі. TFS очікує, що розробники завжди будуть підключені до сервера. Це великий мінус. Я особисто вважаю, що TFS менш прозорий щодо організації файлів на сервері та на локальному диску через щільну інтеграцію Visual Studio. Навіть більші прихильники TFS визнають, що його підключена модель реєстрації / виїзду не є привабливим варіантом для розробників, які працюють без зв'язку.

2) Вартість. Ті, хто каже, що TFS не є дорогим, або, мабуть, дуже маленькі магазини, або не відповідають умовам ліцензування TFS. Вам потрібна ліцензія на клієнтський доступ майже за все, що ви робите. Ви менеджер, який просто керує помилками? Вам потрібно близько 250 доларів США ліцензії (до роздрібної ліцензії TFS входить 5). Бізнес-користувач, який просто хоче звітувати про свої проблеми? КАЛ 250 доларів США. Розробник? 250 доларів США (якщо у них немає MSDN, і в цьому випадку він включений). Сервер? 500 доларів США (включено, якщо у вас MSDN). Звичайно, хтось, хто продає вам копію TFS, скаже вам, що відстеження робочих елементів безкоштовне для додаткових користувачів, але ці додаткові користувачі можуть бачити лише ті робочі елементи, які вони самі створюють, а не робочі елементи всієї команди, що не є занадто корисний в командному, спритному середовищі. Все це додається, коли у вас є організація середнього розміру, і стає важко виправдати, коли стільки найкращих у своїй продукції продуктів, як SVN та CruiseControl.net, додаткові витрати становлять 0 доларів. (Справедливості заради TFS, однак, я все ще чекаю на дійсно хороший трекер випусків OSS)

3) Структура проекту. У великих командах з меншою кількістю проектів TFS, ймовірно, буде працювати добре. Якщо ви є власною кількістю невеликих, не зв’язаних або слабо пов’язаних програм для бізнесу, структура TFS може почати ставати надзвичайною. З одного боку, неможливо визначити таксономію самих проектів - ви можете встановити "Зони" в рамках проекту, але всі питання та документи відстежуються разом в основному контексті "проекту". Створення нових "проектів" часто займає багато часу, і це занадто багато для невеликих зусиль. Звичайно, SVN не має нічого подібного, оскільки він зосереджений лише на контролі вихідного коду, але якщо вам потрібна хороша гнучкість для малих проектів, SVN та інший інструмент відстеження проблем може бути кращим вибором.

На мою думку, для чого це варто:

• Для великих команд з великими, добре спланованими проектами в магазині Microsoft, де розробники працюють майже виключно в середовищі IDE, переможцем стає TFS. TFS також виграє, коли вам потрібно централізувати політику у своїх проектах.

• Для ряду невеликих команд, що мають безліч різноманітних, менших проектів, або магазинів, в яких виникає проблема, або команд, у яких розробники працюють відключено від контролю джерел, використовуйте SVN.

Я здивований, що той, хто раніше використовував Subversion, навіть мав би бажання / потребу в контролі джерела TFS.

Мій досвід роботи з TFS (2005) був досить жахливим. Я прочитав усі типи довідок та інструкції щодо того, як правильно структурувати джерело для різних потреб у розробці.

Наша проста ситуація, коли ми маємо магістраль із розробкою основної лінії та гілку інтеграції, куди ми інтегруємо зміни та розгортання, а також гілку випусків для відстеження минулих випусків є дуже поширеною та простою, але ми постійно стикаємось із проблемами.

Мої основні проблеми з TFS:

• Злиття - це БІЛ у порівнянні з підривом.
• Є невиправлені помилки. Я зіткнувся з одним із питань перейменування / злиття, відомого вже 2 роки, і виправлення ніколи не буде випущено в 2005 році. Ми в кінцевому підсумку перемістили нашу гілку в "зламану" папку і зараз її ігноруємо.
• Встановлення блокування файлів лише для читання - це тертя. Хто каже, що мені потрібно редагувати пакетні файли та будувати сценарії всередині TFS, щоб він "перевірив" мене? Subversion знає, які файли змінилися. Там немає замків для читання.
• Швидкість. TFS працює повільно через WAN, і насправді він може бути використаний лише у тому випадку, якщо я ввійшов у свій робочий комп’ютер VPN, що робить мою розробницьку роботу дуже повільною в цілому.
• Відсутність належної інтеграції командного рядка та провідника. Інтеграція IDE дуже приємна для повсякденного Get-Latest, додавання файлів та реєстрації, але коли вам потрібно робити щось у багатьох проектах, приємно мати у своєму розпорядженні хороші інструменти. І перед тим, як хтось стрибне мені в горло, стверджуючи, що tf.exe працює добре ... це насправді не інструмент рядка cmd. Наприклад, перевірка коду не повинна відкривати модальне діалогове вікно.

... список можна продовжувати. Я думаю, що навіть при всій інтеграції є безкоштовні альтернативи, які є набагато кращими.

Ми магазин VS.NET, і ми реалізували:

1. Bugzilla для відстеження проблем
2. Apache Subversion як фонове сховище вихідного коду
3. VisualSVN Server для управління SVN на сервері
4. TortoiseSVN (у Провіднику Windows) та AhnkSVN або VisualSVN (у Visual Studio) на клієнті
5. CruiseControl.NET для автоматизованої збірки

Вартість: 0 доларів Переваги: ​​Безцінне

Якщо ви невелика команда або не готові купувати процес TFS, SVN та інструменти з відкритим кодом - це шлях.

Як зазначали інші, TFS надає вам набагато більше можливостей, ніж SVN, у формі управління проектами тощо. Скориставшись обома та працюючи з дуже великими компаніями у впровадженні TFS, ось мої два центи.

1) Якщо ви використовуєте TFS 2005, оновіть до TFS 2008. Ви будете дякувати мені. У TFS 2008 є маса вдосконалень, які роблять його дієвим.

2) Якщо ви живете в Visual Studio і хочете інтеграцію IDE, скористайтеся TFS. Я використовував інтеграцію SVN і майже завжди повертаюся до використання TortoiseSVN.

3) Якщо вам подобається ідея інтеграції облікових записів із автентифікацією Windows, скористайтеся TFS. Керованість з цього кінця приємна. Для SVN можуть бути гачки - я не впевнений, але якщо вам подобається керування графічним інтерфейсом, TFS важко обіграти.

4) Якщо вам потрібно відстежувати показники або у вас є простіші способи реалізації таких речей, як політика реєстрації, перейдіть до TFS.

5) Якщо у вас є люди, які не зможуть це реалізувати, якщо це не MSFT, перейдіть на TFS.

6) Якщо ви робите більше, ніж просто .NET (робота на Java, Eclipse тощо), використовуйте SVN. Так, є дуже хороші продукти (наприклад, Teamprise), які добре працюють з TFS. Але якщо інші мови не є невеликою частиною вашого магазину, просто дотримуйтесь SVN.

Поза цим, функції SCM обох приблизно еквівалентні. Обидва вони виконують розгалуження та злиття, обидва проводять атомні реєстрації, обидва підтримують перейменування та переміщення. Я думаю, що для людей, які тільки починають працювати з концепцією розгалуження та злиття, приємно мати видимість гілок у Source Control Explorer.

TFS насправді не такий дорогий (1200 доларів, можливо?). Порівняно зі SVN, можливо. Інтеграція до служб звітування та SharePoint є приємною, але знову ж таки, якщо ви не використовуєте це, то це не має значення.

Що б я сказав, це завантажити 180-денну пробну версію TFS і спробувати. Запустіть пробну програму поруч. Я думаю, ти будеш щасливий незалежно від того, в який бік ти підеш.

Як зазначає Убігучі, TFS не є продуктом контролю версій. Купівля TFS з наміром використовувати її лише для контролю версій, очевидно, буде марною тратою грошей. TFS - це інтегрований набір інструментів для автоматизації всіх аспектів управління життєвим циклом додатків (і в основному орієнтований на "Підприємство".

Також за дописом Бен С - я не розумію вашого коментаря щодо замків. У TFS замки взагалі не потрібні. Адміністратори можуть налаштувати TFS на роботу як VSS (функції, що вимагаються деякими "нерозумними" клієнтами), на "Отримати останнє на касі", яке, на мою думку, також робить блокування виїзду.

Але завдяки "звичайному" використанню TFS "виписка" пропонує користувачеві тип блокування - і за замовчуванням має бути "немає". Користувач МОЖЕ обрати реєстрацію виїзду (або блокування реєстрації) - але це не обов’язково. Якщо ви не хочете замки, не використовуйте їх.

TFS відстежує, які користувачі мають виїзди на сервер з різних причин, як з точки зору продуктивності (зробити швидше отримання останньої версії), так і з управління проектами (мені подобається бачити, які розробники перевіряють файли та як довго їх виїжджають).

Я не дуже знайомий із SVN (я його ніколи не використовував) - тому я не можу коментувати, що "злиття гірше з TFS" - і не потрапляв у помилку про злиття, про яку повідомляв Бен С - але у мене було чудово успіх з розгалуженням та злиттям за допомогою TFS.

Я знаю, що один із варіантів використання TFS все ще досить слабкий - для користувачів, які регулярно перебувають у режимі офлайн. TFS - це "Серверний продукт", який передбачає, що користувачі більшу частину часу підключені. Офлайн-досвід покращився у випуску 2008 року (він був похмурим у 2005 році), але йому ще належить пройти довгий шлях. Якщо у вас є розробники, яким потрібно (або вони хочуть) часто відключатись від мережі на тривалий проміжок часу - вам, швидше за все, буде краще SVN.

Ще однією особливістю, яку слід врахувати для шанувальників SVN, які використовують TFS, є SVN Bridge - кодовий комплекс, який дозволяє користувачам використовувати TortiseSVN для підключення до TFS. Я, мій добрий друг і колега, широко його використовую і люблю.

Також мене дивує коментар про відсутність командного рядка - інструменти командного рядка є великими (хоча багато хто вимагає окремого завантаження TFS

Я підозрюю, що коментарі Бена базуються на оцінці випуску 2005 року, який явно був продуктом "Microsoft V1.0". На даний момент продукт знаходиться у версії 2.1, найближчим часом з’явиться версія 3.

TFS огидна. На даний момент я контролюю версії локально, використовуючи SVN (з Live Mesh для резервних копій), оскільки у мене є багато проблем із TFS. Основна проблема полягає у тому, що TFS використовує мітки часу для запису, якщо у вас найновіша версія, і зберігає ці мітки часу на сервері. Ви можете видалити локальну копію, отримати останню версію з TFS, і там буде вказано, що всі файли оновлені. Це безглузда система, яка не дає жодних гарантій, що у вас є правильна версія файлів. Це призводить до численних прикрощів:

• Про редагування будь-якого файлу необхідно повідомити TFS, тому вам потрібно постійно підключатися до сервера.
• TFS заплутаються, якщо ви редагуєте файли за межами IDE. Далі він встановлює всі файли лише для читання в NTFS.

Хоча TFS підтримує злиття, це справді система реєстрації / оплати. Якщо ви редагуєте файл, ви часто виявляєте, що він заблокований для інших розробників. Є способи обійти це, але система така заплутана, що ви завжди зіткнетеся з проблемою. Наприклад, наші розробники виявили, що вони можуть обійти всі файли, які встановлюються для читання лише в NTFS, перевіривши ціле рішення, яке встановлює ексклюзивне блокування всіх файлів. Я робив це кілька разів, тому що субверсія має однаковий синтаксис для замовлення, який не отримує блокування.

Нарешті, Team Explorer (клієнт) - це колосальні 400 МБ, для встановлення сервера TFS потрібні SharePoint і два дні. Інсталятор Subversion в один клік становить приблизно 30 МБ, і він встановить вам сервер менш ніж за хвилину. TFS має багато можливостей, але його основа настільки хитка, що ви ніколи не будете ними користуватися чи піклуватися про них. TFS є дорогим з точки зору ліцензії, і з часом розробники витратять ганьбу на stackoverflow замість написання коду: P

Моя рекомендація, Team System не коштує грошей. Я використовував і те, і після того, як використовував Team System, я намагався знайти подібну заміну. В основному, за що ви платите, - це інтеграція, і ви можете аргументувати підтримку налаштування, але я зміг створити заміну командної системи з невеликим витратою часу та інтегруванням інструментів разом.

Нещодавно я задав питання про те, що зробили інші, щоб запропонувати альтернативу Team System. Я також перелічую інструменти розробки, які я використовував для створення заміни. Сподіваємось, за допомогою цієї відповіді та запитання, яке я задав, ви зможете знайти те, що вам підходить.

Я не ненависник Team Team, я просто не думаю, що це коштує грошей. Це дуже приємний інструмент, і якщо ви не проти заплатити за нього ціну, то неодмінно використовуйте його. Це була вся причина, через яку я створив заміну, яку я придумав. Мені потрібна функціональна команда Team System.

Ось версія з відкритим кодом VisualSVN під назвою Ankhsvn . Це набагато краще зараз, коли колабнет взяв його на себе.

Якщо все, що вам потрібно - це керування джерелом, TFS є надмірним. Один із моїх попередніх роботодавців мав TFS, VSS та Subversion на своєму підприємстві. У нас не було Active Directory або Exchange Server 2003 на нашому підприємстві, тому ми в підсумку створили окремих користувачів на сервері TFS, щоб розробники могли цим користуватися. У нас були такі самі проблеми зі злиттям, про які згадував Бен Ширман, поряд з іншою поведінкою баггі, яка штовхала нас до Subversion.

Чи буде TFS правильним викликом для вас, це частково залежатиме від вашого бюджету, розміру вашої команди розробників та кількості часу та персоналу, доступного для конфігурації / обслуговування вашого рішення. Якщо вам потрібні додаткові можливості відстеження проблем, робочих елементів та статистики проектів, які надає TFS, можливо, вам варто витратити час на пошук інших альтернатив. Такі продукти, як JIRA (від Atlassian Systems) або Trac, добре інтегруються з Subversion і забезпечують нагляд за проектом або менеджером програми за нижчою ціною.

В ідеальному середовищі з Active Directory, Exchange Server 2003 або новішою версією та спеціалізованим персоналом для сховища, TFS, швидше за все, буде гарним вибором.

Я використовував як на роботі, так і вдома. Обидва вони самі по собі дуже круті. Єдиний раз, коли я рекомендую використовувати TFS, це те, якщо ви будете використовувати більше функцій, ніж просто джерело управління. Якщо вам потрібен лише контроль джерела, ви не можете помилитися зі SVN, і ось чому.

1. VisualSVN Server Це повноцінний SVN-сервер з приємним плагіном для управління ним. Це дозволяє використовувати автентифікацію Windows прямо через інтерфейс користувача. Легко.

2. Черепаха Її черепаха, досить сказано.

3. ankhsvn Це чудовий плагін SCC. Для тих, хто бажає повної інтеграції VS IDE, остання версія - це повний плагін SCC. Отже, ви отримуєте повну інтеграцію безкоштовно.

Вищевказане налаштування на 100% безкоштовне і допоможе вам отримати все, що потрібно для контролю джерел.

TFS - це не лише управління джерелами. Якщо ви використовуєте цілий пакет, який пропонує TFS, відстеження помилок, збірки, звіти тощо, тоді TFS є цілком надійним вибором (звичайно, кращим, ніж Rational). TFS також добре інтегрується з Active Directory.

Хоча якщо ви просто говорите про SCM, то я віддаю перевагу SubVersion. Мені не дуже подобається інтеграція IDE. Мені також подобається угода SVN щодо структури Trunk / Tags / Branches та відносна простота перемикання між гілками. Злиття здавалося простішим у TFS. Користувальницький інтерфейс Черепахи б'є руки TFS, особливо щодо додавання файлу до репо.

Я б сказав, що це насправді залежить від ваших потреб. TFS дуже приємний, я ним широко користувався, але він дуже спрямований на корпоративний рівень, якщо вам не потрібні всі ці функції, це може не знадобитися. Якщо вам потрібні ці функції (особливо розгалуження, масштабованість, відстеження робочих об’єктів тощо), вони коштують кожної копійки. Майте на увазі, що TFS включає відстеження помилок, відстеження робочих елементів та інші функції, що не підлягають контролю джерела. Якщо у вас є кілька гілок або якщо ви стикаєтесь з певною відсутністю можливостей чи інших функцій у Subversion, можливо, буде гарною ідеєю перейти. Але, не маючи вагомих причин переключення, ви, мабуть, повинні уникати витрат та продуктивності, пов’язаних із перемиканням систем управління джерелом.

Дуже широко використовуючи обидва варіанти, Клін зауважив, зазначивши: "TFS включає відстеження помилок, відстеження робочих елементів та інші функції, що не підлягають контролю джерела".

Однак я можу чесно сказати, що SVN і TFS здаються досить рівними щодо масштабованості, і якщо що-небудь управління джерелом SVN має перевагу над TFS завдяки своїй простоті.

Якщо ви хочете відстежувати робочі елементи та помилки поряд із вашим джерелом контролю, тоді ви або використовуєте TFS, або ви використовуєте SVN та деякі інші, можливо, безкоштовні інструменти, такі як bugzilla. Незважаючи на те, що TFS інтегрує як контроль джерел, так і відстеження робочих об'єктів разом, я щиро думаю, що MS повинна була б його безкоштовно подарувати як вибачення за зловживання стільки розробників VSS протягом багатьох років.

Я використовував як SVN, так і TFS. Головною перевагою використання TFS є щільна інтеграція з Visual Studio. Відстеження помилок, відстеження завдань буде працювати в одному місці. А звіти, створені за цими пунктами, допоможуть зацікавленим сторонам інформувати про стан проекту.

Я працюю над проектом із 5 людьми, і нещодавно ми перейшли зі SVN на TFS. Весь процес був кошмаром. Ми автоматично згенерували код із XMLSpy, і TFS не розпізнає файли, модифіковані поза VS2008. Електроінструменти TFS можуть просканувати ваш замовлення та вирішити цю проблему, але важко пам’ятати про використання цих інструментів. Ще однією проблемою, з якою ми постійно стикаємось, є інструмент злиття за замовчуванням у TFS. Це, безумовно, найгірший інструмент злиття, який я коли-небудь використовував. Можна подумати, що TFS зможе обробляти базові злиття рішень, але поки що це не так.

Вбудований користувальницький інтерфейс дуже корисний, але він також має недоліки. Якщо я оформляю замовлення з мого провідника рішень, іноді додані файли не перевіряються. Якщо я роблю це з вікна Team Source Control, це працює чудово. Чому так? Я з нетерпінням чекаю TFS у VS2010, оскільки я чув про це чудові речі, і SVN далеко не ідеальний, але я би очікував, що деякі з цих функцій функціонують трохи інтуїтивніше.

Адам

TFS чудово підходить для управління проектами та відстеження, однак я вважаю, що контроль над джерелом не такий хороший, як SVN. Ось мої яловичини з TFS:

Модель реєстрації / виселення

Це величезна обман для управління джерелом TFS. На жаль, VS автоматично перевіряє елементи для вас, навіть якщо ви цього не хочете. Я був у ситуації, коли хтось перевіряв деякі файли, а потім їхав у відпустку. Я відповідав за реструктуризацію структури каталогів, але не зміг, оскільки купу файлів було передано цій особі. У графічному інтерфейсі немає способу скасувати оплату, що означало, що це потрібно було робити по черзі в командному рядку. Або мені довелося зрозуміти, як написати сценарій оболонки живлення для цього.

VS потрібно робити все

Іноді я хочу відредагувати текстовий файл і перевірити його. Для цього потрібно запустити VS 2010, який є величезним звіром, просто відредагувати файл і перевірити його. Щось, що зайняло кілька секунд у SVN, зараз займає хвилину .

Як зазначали деякі інші, файли позначаються як прочитані, лише якщо вони не перевірені. Якщо ви зробите його доступним для запису та редагуєте за межами VS, TFS не розпізнає це. Це робить редагування чогось поза VS дратує. Це означає, що запускаємо VS, перевіряємо файл, редагуємо його в іншому редакторі, перевіряємо у VS.

Деякі операції, які були легкими у SVN, зараз є болем

• Можливо, я ще не зрозумів цього, але я виявив, що відкат набору змін був дуже нудним для TFS.

• Додавання файлів до контролю джерел, які не є частиною рішення, є величезною проблемою. Провідник керування джерелом TFS лише показує, які файли перебувають у джерелі керування, а не які (можливо, десь для цього є налаштування, я не знаю). За допомогою Tornoise SVN я міг просто натиснути коміт у папці та вибрати файли, які потрібно додати.

В даний час я спрямовую зусилля на оцінку TFS у своїй компанії на основі Rational Suite, яким ми зараз користуємося. Поки що TFS 2008 переслідує явну справу + заявку на отримання. Інтеграція розробницького середовища - це те, що насправді блищить.

Мої 10 центів:

TFS2005 був жартом - важко встановити і ще важче підтримувати TFS2008 був стабільним - простіший в установці, простіший ремонт та автоматизовані збірки, які працюють. TFS2010 - це EPIC! - встановлення собаки іссасий. Управління дуже легке; це все гарно викладений інтерфейс. Інтегрувати його з VS2008 не так просто, оскільки ви не можете створювати проекти в vs2008, вам доведеться використовувати vs2010 (що дурно). TFS2010 також дозволяє змінити місце розташування проекту спільної точки замість того, щоб мати ці жахливі підпапки TFS2008. TFS2010 також має такі інструменти, як вибухована діаграма, яка дійсно корисна для управління проектами. Це як TFS2010 для всієї виробничої групи, включаючи клієнтів! Це все ще коштує занадто дорого, хоча :(

Також майте на увазі, що TFS вимагає НАБАГАТО більше кінських сил від серверного обладнання. І як мінімум одна ліцензія на сервер Windows, звичайно.

Найкращою практикою, як дотримувалась наша компанія, є використання 2-х серверів: інтерфейс (із вбудованою точкою доступу) та виділений сервер sql у сервісі (ми використовуємо корпоративний кластер). TFS можна встановити на 1 машині, але не слід.

Для порівняння, наш svn-сервер встановлений на віртуальному linux-сервері з 256 Мб оперативної пам’яті та 1 процесором, і все ще швидше на кілька величин при виконанні таких загальних завдань, як checkout-all. Віртуальне обладнання було найнижчим, що міг призначити vshpere! Хоча диск швидкий (SAN).

Я хотів би припустити, що TFS вимагає виділеного обладнання на суму не менше 5000 доларів, тоді як сервер svn (на Linux) може працювати з будь-яким обладнанням, яке застаріло для поточних ОС на базі Windows.

На мій погляд, це залежить від ситуації та середовища, в якому здійснюється проект. Якщо у вас є лише простий, невеликий проект, то SVN - це чудово. Як вже писали деякі, VisualSVN чудово інтегрується у Visual Studio st. Вам не потрібно робити реєстрацію / виїзд за власною файловою системою.

TFS чудово підходить для контролю версій, але ще краще, якщо ви дійсно використовуєте всі його можливості. На мої очі, це справді стає вартим, якщо ви використовуєте, наприклад, робочі елементи як інтегрований репозитарій для обробки звітів про помилки клієнтів, нових запитів на функції та для відстеження прогресу вашого проекту, керуючи завданнями та відповідно до розрахункового часу, використовуваного часу та індикації часу, що залишився.
Що також насправді цікаво, це скористатися функцією пов’язування робочих елементів із реєстрацією вихідного коду. Дивіться тут для отримання додаткової інформації про це.

Ми невелика команда в процесі переходу від SVN до TFS2010. Найбільшою нашою причиною для цього є інтеграція Visual Studio та WebAccess для відстеження помилок, які зараз є частиною TFS.

@ Адам: Сподіваємось, у нас буде кращий досвід. Поки не можу сказати ...

Я використовував SVN протягом останніх 3 років (раніше від VSS), і нещодавно мені довелося перейти на TFS2010. Загальне відчуття полягає в тому, що він вищий, ніж SVN, і за винятком приємної інтеграції із завданнями / помилками, я не бачу, що він має перевагу проти SVN. Швидкість, здається, також дещо повільніша, ніж у SVN.

Якби я зараз вибрав джерело керування, я все одно пішов би з SVN.

Щодо інструментів: - AnkhSVN Visual Studio Plugin настільки ж гарний, як і керування джерелом TFS - Tortoise набагато кращий за аналог TFS

TFS чудово, якщо вам не потрібні не розробники, перейти до pm матеріалів.

Наша служба підтримки повинна брати участь у процесі, і вона просто не вирізала його.

Крім того, управління побудовою у принаймні tfs 2005 є примхливим, і воно навіть не може побудувати проти 2008 slns. Мені дуже не подобається, що вибір мого джерела контролю впливає на вибір розгортання, ось чому моя команда не є магазином svn.

Якби це просто базувалося на контролі джерела, я б пішов із SVN. Безкоштовна надбудова AnkhSVN для Visual Studio була значно вдосконалена у своєму новому випуску. Крім того, ви отримуєте вихідний код для SVN, і документація чудова! Вони змінили деякі таємні речі в TFS 2010 Source Control, і без вихідного коду усунення неполадок може бути дуже страшним. Крім того, ви залежні від команди MSDN для викачування документів, і вони роблять це за власним графіком та на своїй глибині.

З огляду на це, TFS, очевидно, пропонує набагато більше, ніж контроль джерела . Це інструмент ALM . Поєднання його з робочими елементами, звітами, автоматизованими збірками, закритою реєстрацією , автоматизованим тестуванням тощо може надати дуже багате значення, яке ви можете отримати, лише підключивши різні інструменти до SVN. І звичайно, наявність джерела для SVN - це не є безпечним. Я потрапив у сценарії з SVN, де ще були б потрібні тижні, щоб повністю зрозуміти, що відбувається.

Отже, я рекомендую вам поглянути на це з точки зору ALM і подивитися, чи ваша компанія буде використовувати всі функції TFS, чи буде використовувати найкращу в своїй стратегії (наприклад, JIRA).

TFS на милю.

Я ненавмисно створюю для себе занадто багато проблем із використанням файлового підходу SVN. Проблеми з управлінням джерелом, коли я стикався: TFS - 0 проблем протягом 2 років SVN - втрачений рахунок ...

Так, я знаю, що ціна TFS враховує це для більшості компаній, що є такою ганьбою. Держави-члени могли б отримати набагато більше ринкових ресурсів (і прибутку), якби мали розумну модель ціноутворення.