SVN vs Team Foundation Server

votos
74

Alguns meses atrás minha equipe transferido nossa controle de origem até Subversion do Visual SourceSafe , e não foram feliz.

Recentemente eu estive olhando para Team Foundation Server , e pelo menos na superfície, parece muito impressionante. Há alguma grande integração com o Visual Studio, e um monte de ótimas ferramentas para DBAs, testadores, gerentes de projeto, etc.

A diferença mais óbvia entre esses dois produtos é o preço. É difícil de bater Subversion (gratuito). Team Foundation Server é muito caro, por isso, os recursos extras que realmente tem que chutar Subversion nas calças.

  • Alguém tem experiência prática com os dois?
  • Como eles se comparam?
  • É Team Foundation Server realmente vale o custo?
Publicado 07/08/2008 em 01:43
fonte usuário
Em outras línguas...                            


26 respostas

votos
87

Aqui estão as maiores diferenças entre os dois para mim, e eu usei tanto:

1) TFS é bastante intimamente ligado ao "caminho do Visual Studio" de fazer o desenvolvimento. Isso não quer dizer que TFS está intimamente ligado ao VS IDE, isso significa que TFS se esforça para manter o familiar "check-in" "check out" paradigma / de Visual SourceSafe, mesmo quando ele realmente não é um modelo adequado anymore. O conceito de subversão da "comprometer" / "update" é muito mais realista quando você tem desenvolvedores que podem passar o tempo desconectado da rede. TFS espera que os desenvolvedores sempre ser conectado ao servidor. Isso é um grande menos. Eu pessoalmente acho TFS ser menos do que transparente sobre como os arquivos são organizados no servidor e no disco local por causa do apertado integração do Visual Studio. Mesmo defensores maiores do TFS admitir que seu modelo / check-out conectado check-in não é uma opção atraente para os desenvolvedores que trabalham desconectado. Em um clima onde as pessoas estão começando a olhar para as opções DVCS como git e mercurial sobre SVN, TFS de "check out" modelo parece um pouco como um dinossauro.

2) custo. Aqueles que dizem que TFS não é caro ou são, provavelmente, muito pequenas lojas, ou não estão em conformidade com os termos de licenciamento do TFS. Você precisa de uma Client Access License para danado perto de tudo que você faz. Você é um gerente que apenas gere os bugs? Você precisa de uma CAL ~ $ 250 (Há 5 incluído com um varejo TFS License). Um usuário do negócio que só quer relatar suas questões? A CAL $ 250. Um desenvolvedor? $ 250 (A menos que tenham MSDN caso em que está incluído). O servidor? $ 500 (incluído se você tiver MSDN). Claro, alguém vendendo-lhe uma cópia do TFS irá dizer-lhe que o rastreamento de item de trabalho é gratuito para usuários adicionais, mas esses usuários adicionais só pode ver os itens de trabalho que eles próprios criam, e não itens de trabalho de toda a equipa, que não é muito útil em um ambiente ágil equipa orientada. Tudo isso acrescenta-se quando você tem uma organização de médio porte, e torna-se difícil de justificar quando tantos produtos best-of-breed como custo incremental do SVN e CruiseControl.net é de R $ 0. (Para ser justo com TFS, embora, eu ainda estou à espera de um realmente bom issue tracker OSS)

3) estrutura do projecto. Em grandes equipes com um número menor de projetos, TFS provavelmente irá funcionar bem. Se você é um número de pequenas, desconexos ou vagamente conectados aplicativos de linha de negócios internos, a estrutura da TFS pode começar a se tornar arrogante. Por um lado, não é possível definir uma taxonomia dos próprios projetos - você pode configurar "áreas" dentro de um projeto, mas todas as questões e documentos são controlados em conjunto no contexto básico de um "projeto". A criação de novos "projetos" é muitas vezes demorado, e é um exagero para pequenos esforços. Claro, SVN tem nada do tipo, uma vez que incide apenas sobre controle de código fonte, mas se você precisar de uma boa flexibilidade pequeno-projeto, SVN e outra ferramenta de acompanhamento de questões pode ser uma escolha melhor.

Minha opinião, para o que vale a pena:

  • Para grandes equipes com grandes projetos bem orçados, em uma loja de Microsoft, onde os desenvolvedores trabalham quase que exclusivamente dentro do IDE, TFS é o vencedor. TFS também ganha quando você precisa para fazer valer centralmente política com seus projetos.

  • Para um número de equipes pequenas, com muitos, variados projetos menores, ou lojas onde o custo é um problema, ou equipes que têm desenvolvedores que trabalham desconectada do controle de origem, ir com SVN.

Respondeu 25/10/2008 em 15:33
fonte usuário

votos
48

Estou surpreso que alguém que tenha usado Subversion no passado teria sequer um desejo / necessidade de controle de origem do TFS.

Minha experiência com o TFS (2005) tem sido bastante horrível. Eu li todos os tipos de whitepapers e orientação sobre como estruturar adequadamente a sua fonte para diversas necessidades de desenvolvimento.

Nossa situação simples, onde temos um tronco com o desenvolvimento da linha principal, e ramo de integração, onde podemos integrar mudanças e implantar a partir, e um ramo releases para manter o controle de versões anteriores é muito comum e simples, mas estamos continuamente correndo em problemas.

Minhas principais questões com TFS:

  • A fusão é uma dor em comparação com a subversão.
  • Há erros não corrigidos. Corri para um sobre a renomeação / fusão que tem sido conhecido por 2 anos e uma correção não será lançado para 2005. Acabamos mudando nossa filial para uma pasta "quebrado" e nós ignorá-lo agora.
  • Colocar somente leitura bloqueios em seus arquivos é o atrito. Quem diz que eu preciso para editar arquivos em lote e construir scripts de dentro do TFS para que ele irá "check-out" para mim? Subversion sabe quais arquivos alterados. Não há bloqueios somente leitura lá.
  • Rapidez. TFS é o cão-lenta através de uma WAN, e é realmente apenas utilizável se eu VPN no meu computador de trabalho, o que torna a minha experiência dev realmente geral lento.
  • Falta de bom de linha de comando e integração explorador. integração IDE é muito bom para o dia dia-a-Get-Latest, adicionar arquivos e check-in, mas quando você precisa fazer as coisas através de muitos projectos, é bom ter boas ferramentas à sua disposição. E antes que alguém salta na minha garganta alegando tf.exe funciona bem ... não é realmente uma ferramenta de linha de cmd. Por exemplo, o check-in de código não deve aparecer uma janela modal.

...A lista continua. Eu acho que mesmo com toda a integração, existem alternativas livres que são muito superior.

Respondeu 29/08/2008 em 21:19
fonte usuário

votos
46

Entrei para um projeto Open Source sobre no CodePlex, recentemente. Eles usam TFS para o seu controle de origem e eu tenho que dizer que é absolutamente magnífico. Estou muito impressionado com ele, até agora. Eu sou um grande fã da integração IDE e como é fácil a ramificar e marcar o seu código. Adicionando uma solução para controle de origem é algo como dois cliques, se você já tenho tudo configurado corretamente.

Agora. Vale a pena o preço elevado? Acho que não. O benefício para trabalhar em projetos no CodePlex é deixa-me ter a experiência com o TFS que eu preciso, no caso em que eu tenho que usá-lo em algum lugar mais tarde. Se você quer uma boa integração IDE para o seu controle de origem, ir pegar VisualSVN pacote de integração. É um investimento muito, muito mais barato para ter um monte das mesmas características (gratuito em computadores sem domínio BTW).

Respondeu 07/08/2008 em 01:52
fonte usuário

votos
42

Nós somos uma loja de VS.NET, e nós implementadas:

  1. Bugzilla para acompanhamento de problemas
  2. Subversion como um repositório de código fonte back-end
  3. VisualSVN servidor para o gerenciamento SVN no servidor
  4. TortoiseSVN (no Windows Explorer) e AhnkSVN ou VisualSVN (em Visual Studio) no cliente
  5. CruiseControl.NET para compilações automatizado

Custo: US $ 0 Benefícios: Priceless

Se você é uma equipe pequena, ou não está pronto para comprar as ferramentas de processo TFS, SVN e código aberto que são o caminho a percorrer.

Respondeu 14/08/2009 em 22:11
fonte usuário

votos
23

Como outros apontaram, TFS lhe dá muito mais recursos, em seguida, SVN faz na forma de gerenciamento de projetos e tal. Tendo usado tanto, e trabalhou com grandes empresas na implementação TFS, aqui está meus dois centavos.

1) Se você estiver usando TFS 2005, a atualizar para TFS 2008. Você vai me agradecer. Há uma tonelada de melhorias no TFS 2008, que o tornam viável.

2) Se você mora em Visual Studio e você quer a integração IDE, ir com TFS. Eu usei a integração SVN e quase sempre cair de volta para usando TortoiseSVN.

3) Se você gosta da idéia de contas sendo integrado com a autenticação do Windows, vá com o TFS. O gerenciamento de esse fim é bom. Pode haver ganchos para SVN - Eu não sou positivo, mas se você gosta do gerenciamento orientado GUI, TFS é difícil de bater.

4) Se você precisa controlar métricas ou ter maneiras mais fáceis de implementar coisas como políticas de check-in, ir com TFS.

5) Se você tem pessoas que não vão implementá-lo se não for MSFT, ir com TFS.

6) Se você fizer mais do que apenas .NET (trabalho Java, Eclipse, etc) ir com SVN. Sim há muito bons produtos lá fora (como Teamprise) que funcionam bem com o TFS. Mas a menos que as outras línguas são uma pequena parte de sua loja, ficar com SVN.

Fora isso, as características de SCM de ambos são cerca equivalente. Ambos fazem ramificação e mesclagem, as duas fazer check-ins atômicos, ambos renomeações de apoio e movimentos. Eu acho que para as pessoas apenas começando com o conceito ramificação e mesclagem, tendo os ramos sejam visíveis em Source Control Explorer é agradável.

TFS realmente não é tão caro ($ 1200 talvez?). Comparado ao SVN é, talvez. A integração com o Reporting Services e SharePoint é bom, mas, novamente, se você não está usando isso, então não importa.

O que eu diria é para baixar o julgamento de 180 dias do TFS e dar-lhe um ir. Executar um side-by-side julgamento. Acho que você vai ser feliz, não importa que caminho você vai.

Respondeu 07/09/2008 em 15:00
fonte usuário

votos
16

Como aponta Ubiguchi TFS não é um produto de controle de versão. Comprar TFS com a intenção de usá-lo apenas para controle de versão seria claramente um desperdício de dinheiro. TFS é um conjunto integrado de ferramentas para automatizar todos os aspectos de Application Lifecycle Management (e muito bem orientada para "A Empresa".

Também por mensagem de Ben S - Eu não entendo o seu comentário sobre bloqueios. Bloqueios não são necessários em TFS em tudo. Os administradores podem configurar o TFS para trabalhar como VSS (características exigidas por alguns clientes "imprudentes") em "Get-Últimas sobre Checkout" que eu acredito que também faz um bloqueio de check-out.

Mas através do uso "normal" de TFS um "check-out" solicita um usuário para o tipo de bloqueio - eo padrão deve ser "nenhum". Um usuário pode selecionar um check-out (ou um check-in lock) - mas não é necessária. Se você não quer fechaduras, não usá-los.

TFS não controlar quais usuários têm check-outs no servidor para vários tanto de desempenho razões (fazer chegar-latest mais rápido) e gerenciamento de projetos (eu gosto de ver o que os desenvolvedores tem arquivos check-out e por quanto tempo os seus check-outs são).

Eu não sou real familiarizado com SVN (eu nunca usei-o) -, então não posso comentar que "mergeing é pior com o TFS" - e não ter atingido o bug fusão Ben S informou - mas eu tive grande sucesso com ramificação e mesclagem usando TFS.

Um caso de uso Eu sei TFS ainda é bastante fraco em é para usuários que estão regularmente "offline". TFS é um "Produto Servidor", que assume os usuários estão conectados a maior parte do tempo. A experiência offline melhorado na versão 2008 (que era sombrio em 2005), mas ainda tem um longo caminho a percorrer. Se você tem desenvolvedores que precisam (ou querem) para muitas vezes, ser desconectado da rede por longos períodos de tempo - você provavelmente melhor fora com SVN.

Outro aspecto a considerar para os fãs do SVN que estão usando o TFS é a Ponte SVN um codeplex que permite aos usuários utilizar TortiseSVN para se conectar ao TFS. Eu bom amigo e colega meu utiliza extensivamente e adora.

Também o comentário sobre a falta de linha de comando me surpreende - as ferramentas de linha de comando são extensas (embora muitos requerem um download separado do TFS Power Tools

Eu suspeito que os comentários de Ben são baseados em um eval da versão 2005 que era claramente um produto "Microsoft V1.0". O produto está atualmente em 2.1 com a versão 3 que vem no futuro próximo.

Respondeu 07/09/2008 em 14:31
fonte usuário

votos
10

TFS é hediondo. Neste momento eu versão controle localmente usando SVN (w / Live Mesh para backups) porque eu tenho alguns muitos problemas com TFS. O principal problema é TFS usa carimbos de tempo para gravar, se você tem a versão mais recente, e armazena esses carimbos de tempo no servidor. Você pode excluir a cópia local, receber as últimas do TFS, e ele vai dizer todos os arquivos estão atualizados. É um sistema de bobo que não lhe dá nenhuma garantia de que você tem a versão correta dos arquivos. Isso resulta em inúmeros aborrecimentos:

  • TFS precisa ser informado quando qualquer arquivo é editado, então você precisa estar conectado ao servidor em todos os momentos.
  • TFS ficar confuso se você editar arquivos fora do IDE. Além disso ele define todos os arquivos como somente leitura no NTFS.

Enquanto TFS suporta fusão, é realmente um sistema de check-in / check-out. Se você editar um arquivo muitas vezes você vai achar que ele está bloqueado para outros desenvolvedores. Existem maneiras de contornar isso, mas o sistema é tão complicado que você sempre vai correr para o problema. Por exemplo, nossos desenvolvedores descobriram que eles podem obter em torno de todos os arquivos a ser definida como somente leitura no NTFS, verificando-se uma solução completa, que define um bloqueio exclusivo em todos os arquivos. Eu fiz isso algumas vezes porque a subversão tem a mesma sintaxe para check-out, que não adquirir um bloqueio.

Finalmente Team Explorer (o cliente) é uma gritante 400 MB, servidor TFS requer SharePoint e dois dias para instalar. A subversão um instalador clique é cerca de 30 MB e vai instalar o servidor para você em menos de um minuto. TFS tem muitos recursos, mas a sua fundação é tão instável você nunca vai usar ou se preocupam com eles. TFS é caro em termos da licença, e nas desenvolvedores tempo vai perder ranting sobre stackoverflow, em vez de escrever código: P

Respondeu 14/08/2009 em 22:02
fonte usuário

votos
8

Aqui está uma versão de código aberto do VisualSVN chamado AnkhSVN . Sua muito melhor agora que collabnet tomou sobre isso.

Respondeu 29/08/2008 em 21:51
fonte usuário

votos
8

Minha recomendação, Team System é não vale o dinheiro. Eu tenho usado tanto e depois de usar o Team System, tentei encontrar um substituto similar. Basicamente o que você está pagando é a integração e você poderia argumentar o apoio personalização, mas eu tenho sido capaz de criar um substituto Team System com um pouco de tempo e integração de ferramentas juntos.

Recentemente, fez uma pergunta sobre o que outros têm feito para chegar a uma alternativa Team System. Eu também listar as ferramentas de desenvolvimento que eu usei para criar a substituição. Esperemos que com esta resposta e a pergunta que eu perguntei, você pode encontrar o que funciona para você.

Eu não sou um hater Team System, eu só não acho que vale a pena o dinheiro. É uma ferramenta muito agradável e se você não se importa pagar o preço por isso, então por todos os meios usá-lo. Foi toda a razão eu criei a substituição eu vim com. Eu queria que o Sistema funcionalidade Equipe fornecido.

Respondeu 17/08/2008 em 03:30
fonte usuário

votos
7

Se tudo que você precisa é de controle de origem, TFS é um exagero. Um dos meus empregadores anteriores tinha TFS, VSS, e Subversion em sua empresa. Nós não tínhamos Active Directory ou o Exchange Server 2003 em nossa empresa, então acabamos criando usuários separados no servidor TFS para que os desenvolvedores podem usá-lo. Tivemos os mesmos tipos de problemas com a fusão que Ben Schierman mencionado, juntamente com outro comportamento de buggy que nos empurrado para Subversion.

Se TFS é a chamada direita para você vai depender em parte do seu orçamento, o tamanho de sua equipe de desenvolvimento, e a quantidade de tempo e pessoal disponíveis para a configuração / manutenção de sua solução. Se você quer o problema adicional de rastreamento, item de trabalho e capacidades de estatísticas de projeto que TFS oferece, pode valer a pena o seu tempo a olhar para outras alternativas. Produtos como JIRA (de Sistemas Atlassian) ou Trac integrar-se bem com o Subversion e fornecer o tipo de supervisão de um projecto ou programa de gerente pode por um preço menor.

Em um ambiente ideal, com o Active Directory, Exchange Server 2003 ou superior, e uma equipa dedicada para o repositório, TFS é mais provável que seja uma boa escolha.

Respondeu 08/09/2008 em 19:35
fonte usuário

votos
6

Eu tenho usado tanto no trabalho como em casa. Eles são ambos muito legal em seu próprio direito. A única vez que eu recomendo usar TFS, porém, é se você estará usando mais recursos do que apenas o controle de origem. Se tudo que você precisa é de controle de origem você não pode errar com SVN e é por isso.

  1. VisualSVN servidor Isso é um servidor completo SVN com um plugin agradável para gerenciá-lo com. Ele permite que você use o Windows autenticação direita através da interface do usuário. Fácil.

  2. Tortoise Sua tartaruga, disse o suficiente.

  3. AnkhSVN É um ótimo plugin SCC. Para aqueles que querem completo VS integração IDE a versão mais recente é um plugin completo SCC. Então, agora você pode obter plena integração gratuitamente.

O conjunto acima se é 100% gratuito e você irá obter através de qualquer coisa que você precisa para controle de origem.

Respondeu 08/09/2008 em 19:46
fonte usuário

votos
4

TFS não é apenas sobre controle de origem. Se você usar todo o pacote que TFS oferece, rastreamento de bugs, constrói, relatórios, etc, em seguida, TFS é uma escolha bastante sólido (certamente melhor do que Rational). TFS também se integra bem com o Active Directory.

Embora se você está apenas falando sobre SCM, então eu prefiro subversão. Eu realmente não gosto de integração IDE. Eu também gosto de convenções de SVN de Tronco / Tags estrutura / Ramos, ea relativa facilidade de alternar entre os ramos. Fusão parecia mais fácil no TFS embora. UI tartaruga bate as mãos de TFS para baixo, porém, especialmente no que diz respeito à adição de um arquivo para um repo.

Respondeu 29/08/2008 em 22:27
fonte usuário

votos
3

TFS é ótimo para gerenciamento de projetos e rastreamento, porém, sinto o controle da fonte não é tão bom quanto SVN. Aqui estão as minhas beefs com TFS:

Check-in / modelo de Saída

Este é um grande golpe para o controle de origem do TFS. Infelizmente, VS verifica automaticamente os itens para você, mesmo que você não quer. Eu estive em uma situação onde alguém check-out alguns arquivos e, em seguida, entrou de férias. Eu estava encarregado de reestruturar a estrutura de diretórios, mas foi incapaz de porque um monte de arquivos foram check-out para essa pessoa. Não há nenhuma maneira na GUI para anular a saída, o que significava que tinha que ser feito um a um na linha de comando. Ou eu tinha que descobrir como escrever um script shell poder para isso.

VS é necessário para fazer tudo

Às vezes eu quero editar um arquivo de texto e verificá-lo. Isso me obriga a inicialização VS 2010, que é uma enorme besta, apenas para editar um arquivo e check-in. Algo que levou alguns segundos com SVN agora me leva um minuto .

Como alguns apontou, arquivos são marcados somente leitura se não são verificados. Se você torná-lo gravável e editá-lo fora do VS, TFS não vai reconhecer isso. Isso faz com que a edição algo fora de VS irritante. Isto significa, disparando-se VS, verificando o arquivo, editá-lo em outro editor, o check-in no VS.

Algumas operações que eram fáceis no SVN são agora uma dor

  • Talvez eu não tenha percebido ainda, mas eu achei que reverter um conjunto de alterações foi muito tedioso com o TFS.

  • Adicionando arquivos para controle de origem, que não são parte de uma solução, é uma dor enorme. O TFS explorer controle de origem mostra apenas os arquivos que estão no controle de origem, e não quais não são (talvez haja uma configuração em algum lugar para isso, eu não sei). Com Tortoise SVN, eu poderia simplesmente pressione Commit em uma pasta e selecione quais arquivos para adicionar.

Respondeu 21/12/2010 em 13:36
fonte usuário

votos
3

Eu estou trabalhando em um projeto com 5 pessoas e que recentemente mudou de SVN para TFS. Todo o processo tem sido um pesadelo. Temos auto código gerado a partir de XMLSpy, e não TFS não reconhecer os arquivos modificados fora do VS2008. As ferramentas TFS Poder pode verificar seu check-out e corrigir este problema, mas é uma dor de ter que se lembrar de usar essas ferramentas. Outro problema que constantemente correr em é a ferramenta fusão padrão no TFS. É de longe o pior ferramenta de fusão que já usei. Alguém poderia pensar que TFS seria capaz de lidar com fusões solução básica, mas até agora isso não foi o caso.

O construído em interface de usuário é muito útil, mas também tem falhas. Se eu fazer o checkout do meu Solution Explorer, por vezes, os arquivos são de que foram adicionados não são verificados. Se eu fizer isso a partir da janela Controle de origem Equipe ele funciona perfeitamente. Por que é que? Estou ansioso para TFS no VS2010 como tenho ouvido grandes coisas sobre ele, e SVN está longe de ser perfeito, mas eu teria esperado alguns desses recursos para funcionar um pouco mais intuitivamente.

Adão

Respondeu 05/11/2009 em 02:52
fonte usuário

votos
3

Eu tenho usado tanto SVN e TFS. A principal vantagem de usar o TFS é sua integração com Visual Studio. Bug Tracking, rastreamento de tarefas vai tudo em um só lugar. E os relatórios gerados por esses itens vai ajudar as partes interessadas se manter informado sobre o status do projeto.

Respondeu 16/09/2008 em 17:06
fonte usuário

votos
3

Tendo usado tanto extensivamente, acho Wedge foi o dinheiro em anotar "TFS inclui rastreamento de bugs, rastreamento de item de trabalho e outros recursos além de controle de origem".

No entanto, posso dizer honestamente que SVN e TFS parecem bastante iguais em relação à escalabilidade, e se o controle de origem qualquer coisa do SVN tem a vantagem sobre TFS devido à sua simplicidade inerente.

Se você quiser de item de trabalho e de acompanhamento de bugs ao lado de seu controle de origem, então você quer ir para TFS ou você vai com SVN e alguns outros, possivelmente livres, ferramentas como o Bugzilla. Enquanto TFS faz integrar tanto controle de origem e de item de trabalho de rastreamento juntos Eu honestamente acho que MS deve ter dado afastado livre como uma desculpa para abusar de tantos desenvolvedores com VSS ao longo dos anos.

Respondeu 29/08/2008 em 11:08
fonte usuário

votos
3

Eu diria que ele realmente depende de suas necessidades. TFS é muito bom, eu usei-o muito, mas está muito voltado ao nível da empresa, se você não precisa de todos esses recursos, pode não ser necessário. Se você precisa desses recursos (especialmente ramificação, escalabilidade, rastreamento de item de trabalho, etc.) eles valem cada centavo. Tenha em mente que TFS inclui rastreamento de bugs, rastreamento de item de trabalho e outros recursos além de controle de origem. Se você tem vários ramos ou se você está lutando contra alguma falta de recurso ou outro no Subversion, então pode ser uma boa idéia para mudar. Mas barrando uma boa razão para mudar você provavelmente deve evitar o custo e produtividade hit de mudar os sistemas de controle de origem.

Respondeu 07/08/2008 em 06:28
fonte usuário

votos
2

Também ter em mente que TFS requer muito mais cavalos de potência do hardware do servidor. E em licenças de servidor mínimos Indicadores um ofcourse.

Melhores práticas, como a nossa empresa seguiu, é usar 2 servidores: front-end (com SharePoint integrado) e um servidor SQL dedicado no back-end (usamos um cluster empresarial). TFS pode ser instalado em uma máquina, mas não deveria.

Em comparation, o nosso servidor SVN é instalado em um servidor linux virtual com 256 MB de RAM e 1 CPU, e ainda é várias magnitudes mais rápido ao fazer tarefas comuns, como check-out, tudo. O hardware virtual foi o menor vshpere poderia atribuir! Disk é rápido embora (SAN).

Eu whould sugerem que TFS requer hardware dedicado para pelo menos US $ 5000, enquanto servidor SVN (no Linux) pode ser executado com qualquer hardware que é obsoleto para janelas atuais OS baseado.

Respondeu 20/04/2011 em 19:01
fonte usuário

votos
2

Meus 10 centavos:

TFS2005 era uma piada - difícil de instalar e ainda mais difícil de manter TFS2008 era estável - mais fácil de instalador, manutenção mais simples e automatizado constrói esse trabalho. TFS2010 é EPIC! - instalação é eassssyyy cão. Gestão é muito fácil; é tudo uma bem definidos UI. Integração com VS2008 não é tão fácil, já que você não pode criar projetos em vs2008 você tem que usar VS2010 (que é estúpido). TFS2010 também permite que você mude a localização do projeto do SharePoint em vez de ter essas terríveis subpastas da TFS2008. TFS2010 também tem ferramentas como um gráfico de burndown que é realmente útil para gerenciamento de projetos. É como TFS2010 é para toda a equipe de produção, incluindo os clientes! Ele ainda custa maneira muito embora :(

Respondeu 03/05/2010 em 20:10
fonte usuário

votos
2

Atualmente, estou liderando o esforço para avaliar TFS na minha empresa contra o Rational Suite que é o que usamos atualmente. Até agora TFS 2008 está pwning clearcase + clearquest. A integração do ambiente dev é onde realmente brilha.

Respondeu 22/09/2008 em 03:48
fonte usuário

votos
1

Eu usei SVN nos últimos 3 anos (vindo do VSS antes) e, recentemente, tive que mudar para TFS2010. O sentimento geral é que é buggier de SVN e exceto para a boa integração com as tarefas / erros que eu não vê-lo como tendo uma vantagem contra SVN. A velocidade parece também ser um pouco mais lento do que com SVN.

Se eu fosse para escolher um sourcecontrol agora eu ainda iria com SVN.

ferramentas Em relação a: - AnkhSVN Visual Studio Plugin é tão bom quanto o controle de origem do TFS - Tortoise é muito melhor do que a contrapartida TFS

Respondeu 04/04/2012 em 14:49
fonte usuário

votos
1

Somos uma equipe pequena no processo de migração do SVN para TFS2010. Nosso maior motivo para isso é a integração no Visual Studio e do WebAccess para acompanhamento de bugs, que agora faz parte do TFS.

@ Adam: Esperamos ter uma experiência melhor. Não posso dizer ainda ...

Respondeu 23/03/2010 em 15:00
fonte usuário

votos
1

Na minha opinião, depende da situação e do ambiente em que o projeto é feito. Se você tiver apenas um pequeno projeto simples, em seguida, SVN é grande. Como já alguns escreveram, VisualSVN integra-se bem no Visual Studio st você não tem que fazer o check-in / check-out sobre o sistema de arquivos nativo.

TFS é ótimo para controle de versão, mas ainda melhor se você realmente usar todas as suas capacidades. Em meus olhos torna-se realmente vale a pena se você usar - por exemplo - os itens de trabalho como seu repositório integrado para lidar com relatórios de erros ao cliente, novas solicitações de recursos e para acompanhar o progresso de seu projeto, o gerenciamento de tarefas e de acordo com o tempo estimado, utilizado tempo e indicações tempo restante.
O que também é realmente interessante é usar o recurso de associar itens de trabalho com checkins código fonte. Veja aqui para mais informações sobre sobre isso.

Respondeu 14/08/2009 em 22:17
fonte usuário

votos
0

Se apenas com base no controle de origem, eu iria com SVN. O AnkhSVN livre add-in para o Visual Studio foi muito melhorada em sua nova versão. Além disso, você obter o código fonte para o SVN e a documentação é ótimo! Eles mudaram algumas coisas misteriosas no TFS controle de origem de 2010, e sem o código-fonte pode ser muito difícil de solucionar. Além disso, você é dependente da equipe MSDN para bombear para fora do doc e eles fazem isso em sua própria programação e em seu próprio profundidade.

Dito isto, TFS, obviamente oferece muito mais do que o controle de origem . É uma ALM ferramenta. Combinando-a com itens de trabalho, relatórios automatizados constrói, check-in fechado , testes automatizados, etc, podem fornecer algum valor muito rico que você só pode obter com a conexão de ferramentas diferentes com SVN. E, claro, ter a fonte para SVN não é uma prova de falhas. Eu comecei em cenários com SVN, onde ainda teria levado semanas para descobrir totalmente o que estava acontecendo.

Então, eu recomendo que você olhar para ele a partir de uma perspectiva de ALM e veja se a sua empresa vai usar todos os recursos do TFS ou vai com uma estratégia de best-of-breed (por exemplo JIRA).

Respondeu 07/02/2011 em 19:36
fonte usuário

votos
0

TFS é grande, se você não precisa de não-desenvolvedores, para chegar a pm coisas.

O nosso helpdesk precisa estar envolvido no processo, e ele simplesmente não foi cortá-lo.

Além disso, o gerenciamento de compilação no TFS 2005, pelo menos, é attrotious, e não pode até mesmo construir vs 2008 SLNs. Eu realmente não gosto que a minha escolha de controle de origem, afeta minhas escolhas de implantação, é por isso que minha equipe não é uma loja de svn.

Respondeu 08/09/2008 em 19:49
fonte usuário

votos
-3

TFS por uma milha.

I inadvertidamente causar muitos problemas para mim com SVNs abordagem baseada em arquivo. problemas de controle de origem ive experimentado: TFS - 0 problemas mais de 2 anos SVN - perdi a conta ...

Sim, eu sei o preço do TFS fatores-lo para a maioria das empresas, que é uma vergonha. MS pode ter muito mais participação no mercado (e lucro) se tivessem um modelo de preço razoável.

Respondeu 08/12/2010 em 04:42
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more