[OFF] GIT OU SVN
Pessoal, estou iniciando um projeto com um colega de outra cidade e vamos precisar utilizar algum controle de versão, ai gostaria de contar com a experiência de cada um sobre o assunto.
Será um sistema WEB, já trabalhei apenas com o SVN e já tive alguns problemas com ele no que diz respeito a merge. Alguém ai com experiência saberia me dizer se vale a pena mudar para o GIT? e qual deles se sai melhor nesse caso, onde iremos trabalhar em cidades diferentes e sistema web acredito que vão acontecer vários merges.
Obrigado
que tal usar o tfs? ele é grátis para até 5 usuários.
ps; meu teclado está ferrado, não funciona shift nem caps lock...
Tive uma breve experiência com o GitHub, porém como ele mantem seu código exposto (caso não queira pagar pelo serviço), decidi utilizar o tfs, que é gratuito para 5 usuários (como o kerplunk já disse).
Até hoje nunca tive problemas com o tfs, basta entender como ele funciona (push, fetch e pull), para conseguir trabalhar em conjunto com outra pessoa.
Eu testei alguns controles de versão, no começo eu usava o SVN mas como você mesmo viu o merge é muito ruim, o único requerimento que eu tinha na época era que deveria ser um software local, eu não queria serviços como do GitHut, Bitbucket entre outros pois o repositório deveria ficar dentro da empresa, então testei o Git, tentei testar o TFS mas na época ele só permitia instalar em Windows Server, não sei como está hoje, e testei o Mercurial.
O Git e o Mercurial são muito parecidos, no final acabei escolhendo o Mercurial pois gostei mais da integração com o VS.Net na época, pois existia um plugin para ele muito melhor do que do Git, que ainda não vinha integrado com o VS.Net, mas no final o que mais acabo usando é o TortoiseHg para gerenciar ele, a integração com o VS.Net é mais para algumas facilidades como de adicionar um novo arquivo no projeto e ele já estar incluÃdo no controle de versão.
Sei que o Merge no Git e no Mercurial funcionam bem melhor que no SVN, pois eles fazem o merge usando o ancestral comum do arquivo, verificando então primeiro o que mudou em relação a versão em comum deles antes de comparar um com o outro, isso faz com que ele consigo escolher sozinho arquivos que mudaram apenas em um dos ramos, e muitas vezes juntar mudanças simples no mesmo arquivo vindas dos dois ramos. Quando estava escolhendo o Mercurial era considerado o melhor dos dois para merge, não sei hoje como está.
Já tive merges de centenas de arquivos modificados em que os conflitos que tive que revisar na mão não chegavam nem a 10 arquivos, e então era até simples fazer os merge destes arquivos manualmente usando algum programa como o Beyond Compare, que faz o merge em 3 vias (eu diria que é 4 vias), mostrando os arquivos de cada ramo, o arquivo original e o resultado, o qual você pode editar de acordo com o necessário.
O arquivo que mais da trabalho para fazer o merge geralmente são os dos projetos, pois por algum motivo do além o VS.Net decide a ordem que vai criar os elementos dentro dele de forma diferente de um computador para outro, isso só consegui resolver usando um programa para reorganizar este arquivo, pois com tudo em ordem fica fácil fazer o merge pelo Beyond Compare.
Outra dica que posso dar é de não resolver organizar um arquivo de código, por exemplo, reorganizando variáveis, mudando métodos de lugar, etc, se outra pessoa pode também estar editando este mesmo arquivo, pois isso vai fazer o arquivo ficar muito diferente do ancestral o que torna difÃcil comparar ele depois.
Citação::
Merge do SVN se não me engano apenas compara as duas versões que você vai dar o merge, e por isso ele não é nada bom.
Eu testei alguns controles de versão, no começo eu usava o SVN mas como você mesmo viu o merge é muito ruim, o único requerimento que eu tinha na época era que deveria ser um software local, eu não queria serviços como do GitHut, Bitbucket entre outros pois o repositório deveria ficar dentro da empresa, então testei o Git, tentei testar o TFS mas na época ele só permitia instalar em Windows Server, não sei como está hoje, e testei o Mercurial.
O Git e o Mercurial são muito parecidos, no final acabei escolhendo o Mercurial pois gostei mais da integração com o VS.Net na época, pois existia um plugin para ele muito melhor do que do Git, que ainda não vinha integrado com o VS.Net, mas no final o que mais acabo usando é o TortoiseHg para gerenciar ele, a integração com o VS.Net é mais para algumas facilidades como de adicionar um novo arquivo no projeto e ele já estar incluÃdo no controle de versão.
Sei que o Merge no Git e no Mercurial funcionam bem melhor que no SVN, pois eles fazem o merge usando o ancestral comum do arquivo, verificando então primeiro o que mudou em relação a versão em comum deles antes de comparar um com o outro, isso faz com que ele consigo escolher sozinho arquivos que mudaram apenas em um dos ramos, e muitas vezes juntar mudanças simples no mesmo arquivo vindas dos dois ramos. Quando estava escolhendo o Mercurial era considerado o melhor dos dois para merge, não sei hoje como está.
Já tive merges de centenas de arquivos modificados em que os conflitos que tive que revisar na mão não chegavam nem a 10 arquivos, e então era até simples fazer os merge destes arquivos manualmente usando algum programa como o Beyond Compare, que faz o merge em 3 vias (eu diria que é 4 vias), mostrando os arquivos de cada ramo, o arquivo original e o resultado, o qual você pode editar de acordo com o necessário.
O arquivo que mais da trabalho para fazer o merge geralmente são os dos projetos, pois por algum motivo do além o VS.Net decide a ordem que vai criar os elementos dentro dele de forma diferente de um computador para outro, isso só consegui resolver usando um programa para reorganizar este arquivo, pois com tudo em ordem fica fácil fazer o merge pelo Beyond Compare.
Outra dica que posso dar é de não resolver organizar um arquivo de código, por exemplo, reorganizando variáveis, mudando métodos de lugar, etc, se outra pessoa pode também estar editando este mesmo arquivo, pois isso vai fazer o arquivo ficar muito diferente do ancestral o que torna difÃcil comparar ele depois.
OCELOTE,
Só para efeito de curiosidade, o TFS não precisa ser instalado em um servidor, e nem em sua maquina local de desenvolvimento, basta criar uma conta microsoft e fazer a vinculação no Visual Studio (Isto a partir do VS 2013). Além disso, com o TFS é possÃvel criar um [Ô]kanban[Ô] com as tarefas, e cada usuário que for trabalhar na mesma, irá posicionando-se sobre as requisições, isto é muito útil em um desenvolvimento com uma grande equipe. Como já citou acima, o VS cria um elemento diferenciado para o projeto em computadores distintos, isto é chato e faz com que muitas vezes a sincronização não ocorra de forma sutil, e para fazer o merge é um parto. Depois de apanhar muito com isto, aprendi que existe a possibilidade de fazer um commit parcial, com o que realmente é necessário (stage no TFS), ou seja, escolhemos os arquivos que foram alterados (classes, dlls, etc...) e commitamos eles, assim a sincronização fica um pouco menos complicada, e todos os colaboradores não tem tantos problemas para fazer o merge (depende dos casos).
Em fim, o ALTAIR148 precisa fazer alguns testes e verificar o que é melhor e qual ferramenta lhe atenderá de forma completa. Existem muitas, e cada uma delas terá as suas particularidades.
ALTAIR148, quando decidir o que vai utilizar, posta aqui o motivo de ter escolhido a mesma.
Citação::
Mas o problema ai é que precisa usar um serviço de terceiros para hospedar o repositório, no caso o projeto vai ficar em um servidor da Microsoft, e o meu requerimento é que ele ficasse apenas dentro da empresa, e para ter uma instalação local do TFS precisava do Windows Server.
De fato, para ter um repositório local é necessário que o mesmo esteja instalado em um servidor windows.