Na empresa onde trabalho, nós desenvolvedores utilizávamos o SVN e todo mundo desenvolvia direto no TRUNK. Porém agora toda e qualquer alteração é criado um BRANCH e antes de ser aplicado no TRUNCK, esse BRANCH é homologado.
O problema é que esse BRANCH ao chegar para ser aplicado no TRUNK gera muito conflitos nas classes, pois 2 desenvolvedores podem ter criado diferentes BRANCH's e alterado a mesma classe. Isso está causando uma grande dor de cabeça pois precisamos atualizar os BRANCH's com o TRUNCK toda vez que se tem a necessidade de aplicar o BRANCH.
O que preciso?
Existe alguma maneira melhor de se fazer isso com o SVN ou existe outro repositório na qual faça essa função melhor que o SVN?
[quote=Hebert Coelho]Esse tipo de problema sempre vai existir.
Atualmente muita gente tem utilizado o github, mas ele também vai ter esse tipo de problema.[/quote]
Qual a diferença do SVN para o github?? Você saberia me dizer?
Outra coisa, será que existe algum plugin que eu possa tipo reservar a classe? Tipo, quando eu reservo ela só eu poderia alterar e só depois de liberada essa classe outra pessoa poderia utilizar, se é que me entende.
Ou seja, você quer implementar o Microsoft SourceSafe (que funcionava exatamente assim, como se fosse um “synchronized” em código - quando um está mexendo, ninguém pode mais mexer . argh… Acho é que você está com problemas com desenvolvedores que não se entendem
Ou seja, você quer implementar o Microsoft SourceSafe (que funcionava exatamente assim, como se fosse um “synchronized” em código - quando um está mexendo, ninguém pode mais mexer . argh… Acho é que você está com problemas com desenvolvedores que não se entendem :)[/quote]
e o MVS pode ser utilizado dentro do eclipse ou é uma ferramenta à parte? O essencial seria uma ferramenta dentro do eclipse mesmo.
[quote=augustovieira][quote=Hebert Coelho]Esse tipo de problema sempre vai existir.
Atualmente muita gente tem utilizado o github, mas ele também vai ter esse tipo de problema.[/quote]
Qual a diferença do SVN para o github?? Você saberia me dizer?
Outra coisa, será que existe algum plugin que eu possa tipo reservar a classe? Tipo, quando eu reservo ela só eu poderia alterar e só depois de liberada essa classe outra pessoa poderia utilizar, se é que me entende. [/quote]Mas isso você pode fazer com o svn. Existe o chamado LOCK. Você tranca o arquivo até liberar.
O SVN é muito bom em alguns pontos, mas trabalhar com ‘branches’ e ‘merges’ nele é muito, muito, ruim.
O GIt é mais simples e poderoso’. Acho que já sabe o trabalho que é fazer um ‘merge’ no SVN…
Testa o Git ai, não vai se arrepender. Adotamos aqui na meu trabalho há pouco tempo, no começo foi complicado devido a quantidade de recursos que ele oferece(muita coisa pra aprender), mas hoje NINGUEM quer voltar pro SVN.
Apesar do Git ter várias vantagens sobre o SVN, esse é um problema que vai continuar.
Desenvolvimento baseado em Branches cria esse tipo de coisa mesmo.
E quanto mais tempo levar para fazer merges do branch para o trunk, pior esse problema se torna.
Talvez seja mais interessante você passar a desenvolver baseado no trunk mesmo, e usar branches para casos curtos e muito especiais.
Técnicas como Feature Toggles podem ajudar com isso.
Uma observação: evite usar locks em arquivos. Gera mais dor de cabeça do que solução (assim como branches).
[quote=AbelBueno]Apesar do Git ter várias vantagens sobre o SVN, esse é um problema que vai continuar.
Desenvolvimento baseado em Branches cria esse tipo de coisa mesmo.
E quanto mais tempo levar para fazer merges do branch para o trunk, pior esse problema se torna.
Talvez seja mais interessante você passar a desenvolver baseado no trunk mesmo, e usar branches para casos curtos e muito especiais.
Técnicas como Feature Toggles podem ajudar com isso.
Uma observação: evite usar locks em arquivos. Gera mais dor de cabeça do que solução (assim como branches).[/quote]+1 (ainda mais na última linha)
[quote=AbelBueno]Desenvolvimento baseado em Branches cria esse tipo de coisa mesmo.
E quanto mais tempo levar para fazer merges do branch para o trunk, pior esse problema se torna.[/quote]
O trabalho com Git não é baseado em branchs, mas em repositórios locais. Isso te possibilita fazer commits o tempo todo, e fazer merges com o trabalho dos demais constantemente. Fazer merge deixa de ser esse pesadelo que era no svn.
[quote=AbelBueno]Talvez seja mais interessante você passar a desenvolver baseado no trunk mesmo, e usar branches para casos curtos e muito especiais.
Técnicas como Feature Toggles podem ajudar com isso.[/quote]
Se toda a equipe desenvolve no trunk, você vai sofrer cada vez que for baixar o que está no server. Como trabalhar com os branchs do svn são um eterno sofrimento, não tenho outra sugestão de melhora que não seja: largue esse lixo e use git.
[quote=von.juliano][quote=AbelBueno]Desenvolvimento baseado em Branches cria esse tipo de coisa mesmo.
E quanto mais tempo levar para fazer merges do branch para o trunk, pior esse problema se torna.[/quote]
O trabalho com Git não é baseado em branchs, mas em repositórios locais. Isso te possibilita fazer commits o tempo todo, e fazer merges com o trabalho dos demais constantemente. Fazer merge deixa de ser esse pesadelo que era no svn.[/quote]Ainda assim, já tomei conflito entre meu repositório local e do servidor.
Com as tecnologias de hoje eu vejo que esse problema sempre existirá.
O trabalho de mesclar alterações sempre vai existir. No git é mais simples, mas ainda assim depende do tempo que você leva para fazer commit(svn) ou push(git) das suas mudanças. O ato de fazer merge constantemente foi justamente o que falei de desenvolver diretamente no trunk.
[quote=von.juliano]
Se toda a equipe desenvolve no trunk, você vai sofrer cada vez que for baixar o que está no server. Como trabalhar com os branchs do svn são um eterno sofrimento, não tenho outra sugestão de melhora que não seja: largue esse lixo e use git.[/quote]
Não entendi porque baixar atualizações do svn seria pior do que no git. De uma forma ou outra irão sempre acontecer.
@AbelBueno e aminha sugestão é pra você usar o git, pois pelo que disse, indica que não tem prática com a ferramenta. Você vai ver o quão mais fácil será lidar com controle de versão!
Eu uso git no dia a dia. Pra mim é claro que é superior ao SVN.
Só não acho que o problema do augustovieira seja a ferramenta.
Se duas pessoas vão trabalhar nos mesmos arquivos, sempre haverá conflitos.
Para mim a melhor maneira de minimizar os problemas é tratar esses confltos o mais cedo possível.
Por isso estou sugerindo que ele comite sempre para o trunk.
Se no git, você espera meses para dar push das suas mudanças, terá o mesmo problema.
Mesmo que o merge seja mais fácil lá…o problema continuará existindo.
[quote=augustovieira]Olá pessoal, estou com o seguinte problema:
Na empresa onde trabalho, nós desenvolvedores utilizávamos o SVN e todo mundo desenvolvia direto no TRUNK. Porém agora toda e qualquer alteração é criado um BRANCH e antes de ser aplicado no TRUNCK, esse BRANCH é homologado.
O problema é que esse BRANCH ao chegar para ser aplicado no TRUNK gera muito conflitos nas classes, pois 2 desenvolvedores podem ter criado diferentes BRANCH's e alterado a mesma classe. Isso está causando uma grande dor de cabeça pois precisamos atualizar os BRANCH's com o TRUNCK toda vez que se tem a necessidade de aplicar o BRANCH.
O que preciso?
Existe alguma maneira melhor de se fazer isso com o SVN ou existe outro repositório na qual faça essa função melhor que o SVN?[/quote]
TFS (team foundation server) é muito bom tambem. No time que to trabalhamos com Lock e nao existe o inferno do merge imprevisivel. Uma pessoa ta do lado da outra e as tarefas sao bem divididas geralmente um com cada tela, entao nao tem problema de usar lock. Claro que acontece as vezes de um precisar mexer num arquivo comum, ai na hora decide se espera, se adianta outra coisa, se faz pair, se trabalha com o arquivo off e faz merge (previsivel) por conta propria, enfim conversamos para saber o melhor para o todo. Tudo tem prós e contras, vale o que der mais certo pro time. Mas Lock é ruim pra equipes onde as pessoas nao ficam perto da outra ou sem tarefas bem divididas.
