SVN vs.O Team Foundation Server [fechado]

StackOverflow https://stackoverflow.com/questions/4219

  •  08-06-2019
  •  | 
  •  

Pergunta

Alguns meses atrás a minha equipa mudou a nossa fonte de controle sobre a Apache Do Subversion a partir de Visual SourceSafe, e não fomos mais felizes.

Recentemente eu estive olhando para O Team Foundation Server, e pelo menos na superfície, parece muito impressionante.Há alguma grande integração com o Visual Studio, e muitas das grandes ferramentas para que os DBAs, testadores, gerentes de projeto, etc.

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

  • Alguém tem experiência prática com os dois?
  • Como eles se comparam?
  • É o Team Foundation Server realmente vale a pena a despesa?
Foi útil?

Solução

Entrei para um projeto de código Aberto mais no CodePlex, recentemente.Eles usar o TFS para a sua fonte de controle e eu tenho que dizer que é absolutamente magnífico.Estou muito impressionado com ele, até agora.Eu sou um grande fã do IDE de integração e como é fácil para o ramo marca e o seu código.A adição de uma solução de controle de origem é algo como dois cliques, se você já tem tudo configurado corretamente.

Agora.Será que vale a pena o preço elevado?Eu não penso assim.O benefício de trabalhar em projetos no CodePlex é que me permite 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 um bom integração de IDE para o Controle de Origem, vai pegar VisualSVN pacote de integração.É um número muito, muito mais barato do investimento para obter um monte de as mesmas características (free on non-computadores do domínio BTW).

Outras dicas

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

1) TFS é bastante estreita vinculação com o "Visual Studio maneira" de fazer o desenvolvimento. Isso não quer dizer que o TFS está intimamente ligado ao IDE do VS, isso significa que o TFS luta para manter o familiar "check-in"/"check-out" paradigma do Visual SourceSafe, mesmo quando ele realmente não é um modelo adequado mais.A subversão do conceito de "commit"/"atualização" é muito mais realista quando os desenvolvedores, que podem passar o tempo desconectado da rede.TFS espera que os desenvolvedores de estar sempre conectado ao servidor.Isso é um grande sinal de menos.Eu pessoalmente acho TFS para ser menos transparente sobre como os arquivos são organizados no servidor e em seu disco local por causa da estreita integração do Visual Studio.Mesmo TFS os maiores defensores admitem que seus ligado check-in/check-out modelo não é uma opção interessante para os desenvolvedores que trabalham desconectado.Em um clima onde as pessoas estão começando a olhar para a DVCS opções como git e Mercurial mais de CVS, TFS "check out" modelo parece um pouco como um dinossauro.

2) Custo. Aqueles que dizem que o TFS não é caro são provavelmente muito pequenas lojas, ou que não estejam em conformidade com o TFS os termos de licenciamento.Você precisa de uma Licença de Acesso de Cliente para o danado perto de tudo que você faz.Você é um gerente que apenas gerencia os bugs?Você precisa de um ~$250 CAL (Há 5 incluído com um retalho TFS de Licença).Um usuário de negócios que só quer um relatório sobre os seus problemas?UM $250 CAL.Um desenvolvedor?$250 (a Menos que tenham MSDN caso em que ele está incluído).O servidor?$500 (Incluídos se você tiver MSDN).Claro, alguém a vender-lhe uma cópia do TFS vai dizer a você que o controle de item de trabalho é grátis para outros usuários, mas esses usuários adicionais só pode ver os itens de trabalho que eles mesmos criam, e não todo o trabalho da equipe de itens, o que não é muito útil em uma equipe, ambiente ágil.Tudo isso acrescenta-se quando você tiver uma organização de médio porte, e torna-se difícil de justificar quando tantos best-of-breed produtos como o SVN e CruiseControl.net's incremental de custo é de $0.(Na justiça para TFS, porém, eu ainda estou esperando por uma realmente bom OSS issue tracker)

3) A estrutura do projeto. Em grandes equipas, com um número menor de projetos, TFS provavelmente funcionará bem.Se você é um número pequeno, desconexos ou frouxamente ligados linha de aplicativos de negócios em casa, TFS estrutura pode começar a se tornar arrogante.Para uma coisa, não é possível definir uma taxonomia de projetos próprios-você pode definir "Áreas" dentro de um projeto, mas todos os assuntos e documentos de são controladas em conjunto dentro do basic contexto 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, pois centra-se apenas no controle de código de origem, mas se você precisa de um bom pequeno-projeto de flexibilidade, SVN e outro problema de rastreamento de ferramenta pode ser uma escolha melhor.

Minha opinião, por que vale a pena:

  • Para grandes equipes com grandes e bem-projetos orçados, em um Microsoft loja onde os programadores a trabalhar quase que exclusivamente dentro do IDE, do TFS é o vencedor.TFS também ganha quando você precisa centralmente impor a política com seus projetos.

  • Para um número de equipes pequenas, com muitas e variadas, projectos de menor dimensão, ou em lojas onde o custo é um problema, ou de equipes que têm os desenvolvedores que trabalham desconectado da fonte de controle, vá com o SVN.

Eu estou surpreso que alguém que já tenha usado o Subversion no passado, até tenho um desejo/necessidade de TFS de controle de origem.

A minha experiência com o TFS (2005), tem sido bastante horrível.Eu li todos os tipos de artigos & orientações sobre como adequadamente a estrutura de sua fonte para diversas necessidades de desenvolvimento.

Nossa situação simples, onde temos um tronco com linha principal de desenvolvimento, e a integração ramo onde integramos alterações e implantar a partir de, e a liberta do ramo para manter o controle dos últimos lançamentos é muito comum e simples, mas estamos continuamente a execução em problemas.

Minhas principais problemas com o TFS:

  • A fusão é uma DOR na comparação com o subversion.
  • Há sem correção de bugs.Eu corri para um sobre como mudar o nome/fusão que tem sido conhecida há 2 anos e uma correção nunca vai ser lançado para o ano de 2005.Acabamos mudando o nosso ramo para uma "quebrada" pasta e nós ignorá-lo agora.
  • Colocar somente leitura bloqueios em seus arquivos é o atrito.Quem diz que eu preciso para editar arquivos de lote e construir scripts dentro do TFS para que ele "check-out" para mim?Subversão sabe quais arquivos alterados.Não há readonly bloqueios de lá.
  • Velocidade.TFS é cachorro-lenta, através de uma WAN, e ele só pode ser usado se eu VPN em meu computador de trabalho, o que faz com que a minha dev experiência muito lento no geral.
  • Falta de uma boa linha de comando e a integração do explorer.A integração de IDE é muito bom para o dia-a-dia Ficar mais Recente, a adição de arquivos e verificar, mas quando você precisa fazer as coisas através de muitos projetos, é 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 linha cmd-tool.Por exemplo, verificação de código não deve aparecer uma caixa de diálogo modal.

...a lista vai sobre.Eu acho que mesmo com toda a integração, existem alternativas livres que são muito superiores.

Nós somos um VS.NET loja, e implementamos:

  1. Bugzilla para o problema de rastreamento de
  2. Apache Do Subversion como um repositório de código fonte de back-end
  3. VisualSVN Server para o gerenciamento de SVN no servidor
  4. O TortoiseSVN (no Windows Explorer) e AhnkSVN ou VisualSVN (no Visual Studio) no cliente
  5. CruiseControl.NET para automação de builds

Custo:R $0 Benefícios:De valor inestimável

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

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

1) Se você estiver usando o TFS 2005, a atualização para o TFS 2008.Você vai me agradecer.Há uma tonelada de melhorias no TFS 2008 que torná-lo viável.

2) Se você mora no Visual Studio e você deseja a integração de IDE, vá com o TFS.Eu usei SVN integração e quase sempre cair de volta usando o TortoiseSVN.

3) Se você gosta da idéia de contas a ser integrada com a Autenticação do Windows, vá com o TFS.A capacidade de gestão do que é bom.Pode haver ganchos para SVN - eu não sou positivo, mas se você gosta de uma GUI orientada a gestão, o TFS é difícil de bater.

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

5) Se você tem pessoas que não vão implementar isso, se não é MSFT, vá com o TFS.

6) Se você fazer mais do que apenas .NET (Java de trabalho, Eclipse, etc), vá com o SVN.Sim, existem produtos muito bons 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, basta ficar com o SVN.

Fora isso, o SCM características de ambos são aproximadamente equivalentes.Os dois ramificação e mesclagem, o tanto fazer atômica de check-ins, ambos de apoio muda e se move.Eu acho que para as pessoas apenas começando com a ramificação e mesclagem do conceito, tendo os ramos de estar visível no gerenciador de Controle de Origem é agradável.

TFS realmente não é tão caro (r$1.200, talvez?).Comparado com o SVN é, talvez.A integração do reporting services e o SharePoint é bom, mas, novamente, se você não estiver usando, então não importa.

O que eu diria é baixar a avaliação de 180 dias do TFS e dar-lhe um ir.Executar um teste de lado a lado.Eu acho que você vai ser feliz, não importa qual caminho você vá.

Como Ubiguchi aponta o TFS não é um controle de versão do produto.A compra de TFS com a intenção de apenas usá-lo para o Controle de Versão seria claramente um desperdício de dinheiro.TFS é um conjunto integrado de ferramentas para automatizar todos os aspectos do Ciclo de vida de aplicações de Gestão (e praticamente voltada para a "Empresa".

Também por Ben S de pós - eu não entendo o seu comentário sobre bloqueios.Bloqueios não são necessárias em TFS em tudo.Os administradores podem configurar o TFS para trabalhar como VSS (as características exigidas por alguns "insensatos" clientes) De "mais Recente em de Checkout", que eu acredito que também faz um check-out de bloqueio.

Mas, através de um uso "normal" do TFS um "check-out" solicita ao usuário o tipo de bloqueio - e o padrão deve ser "nenhum".Um usuário PODE selecionar um (check-out ou check-in de bloqueio) - mas isso não é necessário.Se você não quer bloqueios, não usá-los.

TFS não controlar o que os usuários têm de check-outs no servidor para vários ambos os motivos de desempenho (fazer chegar-mais recente, mais rápido) e gestão de projetos (eu gostaria de ver o que os desenvolvedores têm arquivos com check-out e por quanto tempo o seu check-outs).

Eu não sou real familiarizado com o SVN (eu nunca usei) - então eu não posso comentar que "mergeing é pior com o TFS" - e ainda não bateu a série de bugs Ben S informou - mas eu tenho tido um grande sucesso com ramificação e mesclagem usando o TFS.

Um caso de uso eu sei TFS é ainda muito fraco, é para os usuários que estão regularmente "off-line".TFS é um "Produto de Servidor" que supõe que os usuários estão conectados a maior parte do tempo.A experiência off-line melhorado no lançamento em 2008 (era sombrio, em 2005), mas ainda tem um longo caminho a percorrer.Se você tiver os desenvolvedores que precisa (ou deseja) para, muitas vezes, ser desconectado da rede durante longos períodos de tempo - você está provavelmente melhor com o SVN.

Outra característica a considerar para o SVN fãs que estão usando o TFS é a SVN Ponte um codeplex, que permite aos usuários usar TortiseSVN para conectar ao TFS.O bom amigo e colega meu usa-lo amplamente e ama-lo.

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

Eu suspeito de Ben comentários são baseados em um eval do lançamento de 2005, que foi claramente um "Microsoft V1.0 produto".O produto está em 2.1 com a Versão 3 que vem no futuro próximo.

TFS é hediondo.Neste ponto eu de controle de versão localmente usando o SVN (w/ Live Mesh para cópias de segurança) porque tenho muitos problemas com o TFS.O principal problema é o TFS usa carimbos de hora para gravar se você tem a versão mais recente, e armazena esses carimbos de data / hora no servidor.Você pode excluir a cópia local, obter o mais recente do TFS, e ele vai dizer a todos os arquivos são atualizados.É uma bobagem sistema que 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 for editado, portanto, você precisará estar conectado ao servidor em todos os momentos.
  • TFS ficar confuso se você editar arquivos fora do IDE.Além disso, todos os conjuntos de arquivos para leitura em NTFS.

Enquanto TFS suporta a fusão, é realmente um check-in/check-out do sistema.Se você editar um arquivo você vai encontrar muitas vezes que ele é bloqueado para outros desenvolvedores.Existem maneiras de contornar isso, mas o sistema é tão complicado, você vai sempre correr para o problema.Por exemplo, nossos desenvolvedores descobriram que eles podem obter em torno de todos os ficheiros que estão a ser definido para só de leitura em NTFS, verificando uma solução completa, que define um bloqueio exclusivo em todos os arquivos.Eu fiz isso algumas vezes, porque o subversion tem a mesma sintaxe para o google checkout, que não aquisição de um bloqueio.

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

Minha recomendação, Team System não vale a pena o dinheiro.Eu tenho usado ambos e depois de usar o Team System, tentei encontrar uma substituição semelhante.Basicamente o que você está pagando é a integração e você pode argumentar a personalização de apoio, mas eu tenho sido capaz de criar um Sistema de equipes de substituição com um pouco de tempo e integração de ferramentas em conjunto.

Eu recentemente uma pergunta no que outros têm feito para vir acima com uma Equipe alternativa de Sistema.Eu também lista as ferramentas de desenvolvimento que eu usei para criar a substituição.Espero, com esta resposta e a pergunta que eu perguntei, você pode encontrar o que funciona para você.

Eu não sou uma Equipa Sistema de hater, eu só não acho que vale a pena o dinheiro.É uma ferramenta muito interessante e se você não se importa de pagar o preço por isso, em seguida, por todos os meios usá-lo.Foi toda a razão que eu criei a substituição veio-me.Eu queria que a funcionalidade de Equipe do Sistema.

Aqui é uma versão de código aberto do VisualSVN chamado Ankhsvn.É muito melhor agora do que collabnet tem tomado mais.

Se tudo o que você precisa é de source control do TFS é um exagero.Um dos meus empregadores anteriores tinha TFS, VSS e Subversão na sua empresa.Nós não tínhamos Active Directory ou o Exchange Server 2003 em nossa empresa, por isso acabamos criando separe os usuários no servidor do TFS, assim os desenvolvedores podem usá-lo.Tivemos o mesmo tipo de problemas com a fusão que Ben Schierman mencionado, juntamente com outros buggy comportamento que nos empurrou para o Subversion.

Se TFS é o direito de chamar 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ível para configuração/manutenção da solução.Se você deseja que o adicional de rastreamento de item de trabalho, e de estatísticas do projeto capacidades que o TFS oferece, pode valer a pena o seu tempo para olhar para outras alternativas.Produtos como o JIRA (da Atlassian Sistemas) ou Trac integrar-se bem com o Subversion e fornecer o tipo de supervisão que um projeto ou programa gerenciador poderá a um preço inferior.

Em um ambiente ideal, com o Active Directory, o Exchange Server 2003 ou superior, e uma equipe exclusiva para o repositório, o TFS é mais provável de ser uma boa escolha.

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 recomendaria usar o TFS, porém, é se você vai usar mais recursos do que apenas o controle de origem.Se tudo o que você precisa é de controle de origem que você não pode dar errado com o SVN e esta é a razão.

  1. VisualSVN Server Que é um completo servidor SVN com um bom plugin para gerenciar com ele.Ele permite que você use a autenticação do windows para a direita através da INTERFACE do usuário.É fácil.

  2. Tartaruga Sua tartaruga, disse o suficiente.

  3. ankhsvn Ele é um grande SCC plugin.Para aqueles que querem completo VS integração de IDE a versão mais recente é um completo SCC plugin.Então agora você pode obter a plena integração de graça.

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

TFS não é apenas sobre a Fonte de Controle.Se você usar todo o pacote que o TFS oferece, acompanhamento de bugs, constrói, relatórios, etc, em seguida, TFS é uma bela escolha sólida (certamente melhor do que Racional).TFS também se integra bem com o Active Directory.

Mas se você estiver falando apenas de SCM, então eu prefiro o SubVersion.Eu realmente não gosto de integração de IDE.Eu também gosto de SVN convenção do Trunk/Tags/Branches estrutura, e a relativa facilidade de alternar entre os ramos.A fusão parecia mais fácil no TFS embora.Tartaruga da INTERFACE do bate TFS mãos para baixo, porém, especialmente no que diz respeito ao adicionar um arquivo a um acordo de recompra.

Eu diria que isso realmente depende das suas necessidades.TFS é muito bom, eu tenho usado com frequência, mas é muito mais que visam a nível de empresa, se você não precisar de todas essas características, ele pode não ser necessária.Se você não precisar desses recursos (especialmente ramos, escalabilidade, controle de item de trabalho, etc.) eles valem cada centavo.Tenha em mente que o TFS inclui o erro de rastreamento, rastreamento de item de trabalho e outros recursos para além do controlo de origem.Se você tiver vários ramos ou se você encontrar-se lutando contra a falta de recurso ou de outro no Subversion, em seguida, pode ser uma boa ideia para mudar.Mas com exceção de um bom motivo para mudar, você provavelmente deve evitar o custo e a produtividade bater de comutação de sistemas de controle de origem.

Depois de ter usado tanto extensivamente, eu acho que Cunha foi sobre o dinheiro, destacando "o TFS inclui o erro de rastreamento, rastreamento de item de trabalho e outros recursos para além do controlo de origem".

No entanto, posso dizer, honestamente, que o SVN e o TFS parecem muito iguais no que diz respeito à escalabilidade, e se alguma coisa SVN do controle de origem tem a borda em TFS, devido à sua inerente simplicidade.

Se você deseja item de trabalho e de acompanhamento de bugs do lado de sua fonte de controle em seguida, você quer ir para o TFS ou você vai com SVN e alguns outros, possivelmente, gratuitamente, ferramentas como o bugzilla.Enquanto o TFS não integrar o controlo da fonte e controle de item de trabalho juntos, eu sinceramente acho o MS deve ter dado gratuitamente como um pedido de desculpas por abusar de tantos desenvolvedores com VSS ao longo dos anos.

Eu tenho usado ambos os SVN e TFS.Principal vantagem de usar o TFS é sua integração com o Visual Studio.Acompanhamento de bugs, Acompanhamento de Tarefas vai tudo em um só lugar.E os relatórios gerados por esses itens vão ajudar a estaca titulares mantenha-se informado sobre o status do projeto.

Eu estou trabalhando em um projeto com 5 pessoas e nós recentemente trocou a partir de SVN para o TFS.Todo o processo tem sido um pesadelo.Temos automática de código gerado a partir de XMLSpy, e TFS não reconhece arquivos modificados fora do VS2008.O TFS Power Tools pode analisar o seu check-out e corrigir este problema, mas é uma dor ter que lembrar de usar essas ferramentas.Outro problema que constantemente está o padrão fusão ferramenta TFS.É de longe o pior fusão ferramenta que eu já usei.Alguém poderia pensar que o TFS seria capaz de lidar com solução básica mescla mas tão longe, que não foi o caso.

A interface do usuário integrada é muito útil, mas também tem falhas.Se eu checkout do meu solution explorer, às vezes, os arquivos são adicionados não são verificados.Se eu fizer isso, da Equipe de Controle de Origem janela ele funciona perfeitamente.Por que isso?Estou ansioso para TFS no VS2010 como eu tenho ouvido coisas boas sobre ele, e o SVN está longe de ser perfeito, mas eu gostaria de ter esperado alguns desses recursos para a função um pouco mais intuitiva.

Adam

TFS é ótimo para gerenciamento de projetos e acompanhamento, no entanto eu sinto o controle de origem não é tão bom como o SVN.Aqui estão os meus beefs com o TFS:

Check-in/Check-out do modelo

Esta é uma grande con para o TFS de controle de origem.Infelizmente, VS verifica automaticamente a existência de itens para você, mesmo se você não quiser.Eu estive em uma situação em que alguém check-out de alguns arquivos e, em seguida, saiu de férias.Eu era o encarregado de reestruturar a estrutura de diretório, mas não foi possível porque um grupo de arquivos foram verificados para essa pessoa.Não há nenhuma maneira na interface de usuário para desfazer o check-out, o que significava que tinha que ser feito um por um na linha de comando.Ou eu tinha que descobrir como escrever um power shell script para fazer isto.

VS é necessário para fazer tudo

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

Como alguns outros apontado, os arquivos são marcados como somente leitura se eles não são verificados.Se você torná-lo gravável e editar-lo fora da VS, o TFS não reconhecer isso.Isto torna a edição de algo fora de VS irritante.Isso significa que, disparando VS, check-out do arquivo, editá-lo com outro editor, check-in no VS.

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

  • Talvez eu ainda não descobri ainda, mas eu achei que a reversão de um changeset era muito entediante com o TFS.

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

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

Meus 10 centavos:

TFS2005 foi uma piada - é difícil de instalar e ainda mais difícil de manter TFS2008 era estável - é mais fácil programa de instalação, de manutenção mais simples e automatizado de compilações de trabalho.TFS2010 é ÉPICO!- a instalação é cão eassssyyy.A gestão é muito mais fácil;é tudo uma bem estabelecidas INTERFACE do usuário.A integração dele com o VS2008 não é tão fácil, pois você não pode criar projectos no vs2008 você tem que usar o vs2010 (que é estúpido).TFS2010 também permite que você altere o sharepoint localização do projecto, em vez de ter aqueles terríveis subpastas de TFS2008.TFS2010 também possui ferramentas como um burndown chart que é realmente útil para o gerenciamento do projeto.É como TFS2010 é para toda a equipe de produção, incluindo os clientes!Ela ainda custa muito embora :(

Também ter em mente que o TFS requer MUITO mais cavalos de potência do hardware do servidor.E, no mínimo, um servidor de windows server licenças claro.

As melhores práticas, como a nossa empresa seguido, é usar 2 servidores:front-end (com integrado do sharepoint), e uma dedicada do sql server back-end (usamos uma empresa de cluster).TFS pode ser instalado em 1 de máquina, mas não deve.

Em comparation, nosso svn instalado no servidor virtual servidor linux com 256mb de ram e 1 cpu, e ainda várias magnitudes mais rápido quando da realização de tarefas comuns, como o google checkout-tudo.O hardware virtual foi o menor vshpere poderia atribuir!O disco é rápido embora (SAN).

Eu whould sugerem que o TFS requer um hardware dedicado para pelo menos us $5000, enquanto servidor svn (no linux) pode ser executado com qualquer hardware que é obsoleto para o atual sistema operativo baseado no windows.

Na minha opinião, isso depende da situação e do ambiente em que o projeto é concluído.Se você tiver apenas um simples, pequeno projeto, então SVN é grande.Como já escrevi, VisualSVN se integra perfeitamente no Visual Studio s.t.você não precisa fazer o checkin/checkout sobre o sistema de arquivo nativo.

TFS é ótimo para controle de versão, mas melhor ainda se você realmente usar todas as suas capacidades.Nos meus olhos, ele torna-se realmente vale a pena se você usar, por exemplo, os itens de trabalho como seu repositório integrado para o tratamento de clientes relatórios de bugs, novas solicitações de recursos e para acompanhar o andamento de seu projeto, gestão de tarefas e de acordo com o tempo estimado, tempo utilizado e o tempo restante indicações.
O que é realmente interessante é usar o recurso de associar itens de trabalho com o código-fonte checkins.Ver aqui para mais infos sobre isso.

Nós somos uma equipe pequena no processo de migração do SVN para TFS2010.O nosso maior motivo para tal é a integração no Visual Studio e o WebAccess para bugtracking, que agora é parte do TFS.

@Adam:Espero que a gente vai ter uma melhor experiência.Não posso dizer ainda...

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

Se eu fosse escolher um sourcecontrol agora eu gostaria de ainda ir com o SVN.

Sobre ferramentas:- AnkhSVN Visual Studio Plugin é tão bom como o TFS controle de origem - Tartaruga é muito melhor do que o TFS contrapartida

TFS é ótimo, se você não precisa de não-desenvolvedores, para obter a pm coisas.

A nossa assistência técnica precisa ser envolvido no processo, e não era apenas cortá-lo.

Também o gerenciamento de compilação no tfs 2005, pelo menos, é attrotious, e não pode mesmo construir vs 2008 slns.Eu realmente não gosto que a minha escolha controle de origem, afecta as minhas opções de implantação, é por isso que a minha equipa não é um svn loja.

Se apenas com base no controle de origem, gostaria de ir com o SVN.O AnkhSVN livre add-in para o Visual Studio foi muito melhorado na nova versão.Além disso, você obter o código fonte via CVS e a documentação é ótimo!!!Eles mudaram alguns arcano coisas no TFS 2010 Controle de Origem, e sem o código-fonte pode ser muito complicado para resolver.Além disso, são dependentes da equipe do MSDN para bombear o doc e eles fazem isso no seu próprio horário, e na sua própria profundidade.

O que está sendo dito, TFS, obviamente, oferece muito mais do que controle de origem.É um ALM ferramenta.Combinando-a com itens de trabalho, relatórios automatizados constrói, gated check-in, testes automatizados, etc.pode fornecer alguns muito ricos valor que você só pode começar com a conexão de diferentes ferramentas com o SVN.E, claro, ter a fonte para o SVN não é uma prova de falhas.Meti-me em cenários com o SVN, onde ele teria ainda levado semanas para ser totalmente descobrir o que estava acontecendo.

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

TFS por uma milha.

Eu, inadvertidamente, causar muitos problemas para mim com SVNs abordagem baseada em arquivo.Fonte de problemas de controle de ive experientes:TFS – 0 problemas ao longo 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 poderia ter muito mais marketshare (e lucro), se tivessem um preço razoável no modelo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top