[OFF] GIT OU SVN

 Tópico anterior Próximo tópico Novo tópico

[OFF] GIT OU SVN

VB.NET

 Compartilhe  Compartilhe  Compartilhe
#473920 - 12/05/2017 17:30:23

ALTAIR148
ARINOS
Cadast. em:Janeiro/2011


Boa tarde,

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

Até mais.

Altair Pereira

Ao encerrar o tópico não se esqueça de agradecer... Não custa nada...

Grupo .NET no Facebook

GRUPO .NET

#473921 - 12/05/2017 18:49:45

KERPLUNK
RIO GRANDE DO SUL
Cadast. em:Junho/2009


Membro da equipe
não importa o controlador de versão, merge é sempre complicado.

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...


_______________________________________________________________________
Gostaria de ter seu sistema Desktop "traduzido" para uma interface web? Podemos conversar...
Virei Oráculo!
The end is nigh, be ready for the nukes!


#473923 - 13/05/2017 10:07:50

GUIMORAES
ITAPETININGA
Cadast. em:Agosto/2009


ALTAIR148

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.



#473925 - 13/05/2017 14:04:06

OCELOT
SOROCABA
Cadast. em:Março/2012


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.



#473935 - 14/05/2017 13:40:44

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe
Procure se informar sobre o BitBucket, ele realmente é uma boa alternativa, usando sourcetree na maquina para fazer merge (com certeza deve ter algo pronto para o vs eu é que nao uso)

WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#473948 - 15/05/2017 09:51:28

GUIMORAES
ITAPETININGA
Cadast. em:Agosto/2009


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.



#473949 - 15/05/2017 10:01:35

OCELOT
SOROCABA
Cadast. em:Março/2012


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.



#473950 - 15/05/2017 10:13:40

GUIMORAES
ITAPETININGA
Cadast. em:Agosto/2009


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.



 Tópico anterior Próximo tópico Novo tópico


Para responder este tópico o login é requerido
Se você já possui uma conta de usuário por favor faça seu login
Se você não possui uma conta de usuário use a opção Criar usuário