Controle de versão cvs, source safe ...

Thread.start() Membro desde: 19/11/2008 14:30:17 Mensagens: 47 Offline

Qual o melhor software para fazer controle de versão ? Qual software de controle de versão aloca um fonte apenas para um usuario , não permitindo que outro possa usar ?

Eu vi isso apenas no Source safe da microsoft.... Alguém conhece um melhor ?

JavaEvangelist Membro desde: 21/02/2008 10:01:31 Mensagens: 463 Offline

Qualquer software de controle versão que se preze faz isso ai que você quer. Eu utilizo o Subversion tanto para projetos pessoais como na empresa. Com as configurações corretas você ativa o lock dos fontes que estão sendo trabalhados...

Lock de fontes remotos?

pra que isso? Cada um que resolva seus conflitos =)
Prefiro muito mais um GIT ou Mercurial

JavaEvangelist Membro desde: 21/02/2008 10:01:31 Mensagens: 463 Offline

Como assim ?? E em casos de equipes de desenvolvimento trabalhando no mesmo fonte ??

Guitar_Men wrote:Como assim ?? E em casos de equipes de desenvolvimento trabalhando no mesmo fonte ??

Use, usa um diff e faz um merge entre o fonte remoto e o local, assim que fazemos, dependendo das alterações da um certo trabalho, mas nada que impessa duas ou mais pessoas de alterar o mesmo fonte.

JavaEvangelist Membro desde: 21/02/2008 10:01:31 Mensagens: 463 Offline

Isso é feito de qualquer forma, mas o recurso do lock é interessante. Muitas vezes você pode optar por trabalhar em outro fonte ja que o seu esta "lockado"...

GUJ Hacker Membro desde: 26/09/2009 09:18:56 Mensagens: 5750 Offline

Fredi wrote:Qual software de controle de versão aloca um fonte apenas para um usuario , não permitindo que outro possa usar ?

Eu vi isso apenas no Source safe da microsoft....

Esse conceito é ultrapassado, mesmo o MS Team Foundation Server (que é o sucessor do MS SourceSafe, que foi descontinuado há séculos) não trava um fonte por padrão*. Em vez disso, é melhor usar o conceito de resolução de conflitos, como o próprio TFS usa. O conceito de travamento de fontes só funciona "mais ou menos" em uma firma pequena, onde as pessoas estão na mesma sala e possam dar pedradas umas nas outras, caso o fonte esteja travado.

* O TFS (que é horrível, por sinal) permite travar um fonte mas isso não é muito usado na prática.

JavaEvangelist Membro desde: 21/02/2008 10:01:31 Mensagens: 463 Offline

entanglement wrote:

Fredi wrote:Qual software de controle de versão aloca um fonte apenas para um usuario , não permitindo que outro possa usar ?

Eu vi isso apenas no Source safe da microsoft....

Esse conceito é ultrapassado, mesmo o MS Team Foundation Server (que é o sucessor do MS SourceSafe, que foi descontinuado há séculos) não trava um fonte por padrão*. Em vez disso, é melhor usar o conceito de resolução de conflitos, como o próprio TFS usa. O conceito de travamento de fontes só funciona "mais ou menos" em uma firma pequena, onde as pessoas estão na mesma sala e possam dar pedradas umas nas outras, caso o fonte esteja travado.

* O TFS (que é horrível, por sinal) permite travar um fonte mas isso não é muito usado na prática.

Discordo sobre a sua visão que o lock de fontes só funciona em empresas pequenas. Trabalho em uma empresa que não é pequena e usamos muito esse recurso aqui, até porque temos alguns desenvolvedores que ficam em outras filiais. O lock é importante em todas as fases do desenvolvimento, inclusive na hora de criar Tags sobre novos releases. O comportamento esperado de um sistema de controle de versão é impossibilitar a criação da mesma caso algum arquivo esteja lockado. É um recurso interessante, usar ou não depende da sua equipe, projeto etc etc etc

Não sei se sua resposta coube a mim também, mas não considero o Lock inutil, só não acho tão viavel, acredito que se você escreveu o fonte, sabe qual parte é sua e qual é do seu companheiro, e vai saber resolver o conflito se houver, lembrando que se você usa algo mais recente que cvs, o conflito só ocorre em edições na mesma linha.

Não vejo problema em ter muita gente mudando o mesmo fonte, algumas vezes as alterações do cliente são pra agora, é o caso do seu parceiro estar ajustando uma nova funcionalidade em determinada tela, e surgiu um BUG nessa mesma tela, o cara que ta com uma nova funcionalidade, que está em desenvolvimento não pode descartar tudo que ele fez, para a correção do bug, o que acontece aqui, é que outro cara pega o bug e o resolve, gera uma nova release para produção com essa correção, faz o commit, e o cara que tava na nova funcionalidade, vai receber essa alteração e ajustar com a nova funcionalidade.

Nunca usei o recurso de Lock, mas ao meu ver não seria possivel a correção do BUG pois a classe está travada pelo usuario 1.

Já trabalhei com sistemas onde o controlador de versão usava o lock e em outro sistema que não usava.

Em ambos os sistemas haviam algumas frentes diferentes que cuidavam de pontos distintos do sistema mas que possuiam algumas classes em comum a serem alteradas.
No sistema que utilizava lock, foi notável a perda de performance da equipe pois um precisava aguardar a alteração do outro e ainda manter o sistema em si, íntegro.

Hoje trabalho sob o conceito de utilização de branches onde esses problemas foram minimizados e o cuidado passou a ser mais exclusivo no momento de fazer o merge para a Head do projeto.
A equipe não sente necessidade de utilizar-se de recursos de lock.

JavaEvangelist Membro desde: 11/04/2006 09:35:56 Mensagens: 343 Offline

Vou escrever o mesmo que escrevi no último slide do workshop que dei sobre git aqui na empresa que eu trabalho.

Use GIT e seja feliz!

O modelo Lock-Modify-Unlock é sim ultrapassado e recomendado somente em algumas situações. Pode pesquisar um pouco mais e vai ver que o Copy-Modify-Merge compensa muito mais que o lock. Como? O tempo necessário para se resolver os conflitos que aparecem no projeto é quase sempre menor que o tempo perdido devido aos locks.

Qualquer coisa, dá uma olhada aqui:

http://www.unix.pro.br/svn/html/svn.basic.vsn-models.html

foxpv wrote:Vou escrever o mesmo que escrevi no último slide do workshop que dei sobre git aqui na empresa que eu trabalho.

Use GIT e seja feliz!

Opoiado.

Virtual Machine Man Membro desde: 15/08/2006 16:15:11 Mensagens: 598 Offline

Aqui na empresa também usavamos o Source Safe. Trocamos para o SVN e compramos um pluggin para o Visual Studio.
O recurso de merge realmente é muito melhor do que dar um lock em alguma classe.

Thread.start() Membro desde: 19/11/2008 14:30:17 Mensagens: 47 Offline

vou explicar o que acontece aqui..... Temos o cvs que não da lock nos fontes em nosso desenvolvimento(java) interno, e funciona bem legal.... o problema e que temos o ERP da Datasul e os consultores vem aqui para desenvolver especificos em(progress) e doda vez os malas sobrepoem alterações importantes e com isso perdemos codigos..... claro que fazemos os backups e depois pedimos para eles consertarem , porem estamos perdendo tempo com isso e o pior prejudicando muitas vezes a logica do negocio .... por isso pensei em um controlador que fizesse o lock.....

O que vcs acham ?

Notícias, artigos e o maior fórum brasileiro sobre Java