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 ?
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 ?
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
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.
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”…
[quote=Fredi]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…[/quote]
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.
[quote=entanglement][quote=Fredi]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…[/quote]
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.
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.
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:
[quote=foxpv]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![/quote]
Opoiado.
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.
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 ?
Esses consultores é que são mal-orientados*. Qualquer modificação, eles deveriam criar um branch ou pelo menos marcar uma tag, para que não mexessem no fonte principal. Vocês também não estão sabendo usar direito o CVS: toda vez que fecharem uma versão, criem uma tag, pelo menos. Aí vocês podem voltar tudo até chegar na tag correta.
Parece que o problema é de BIOS* mesmo.
*Bicho ignorante operando o sistema.
Olá
Exatamente o motivo mais forte para NÃO usar locks e usar um sistema de controle de versões distribuído como o GIT (ou similar)
Assino embaixo do que escreveu o entanglement no que foi cotado por você. (aliás assino ambaixo de praticamente todas as mensagens do entanglement, certamente um dos feras do GUJ e só lamento que se mantenha anônimo).
[]s
Luca
Não vou repetir o que já foi dito, mas concordo.
Aqui, usávamos o JediVCS, que também tinha locks, mas estamos migrando pro subversion, justamente pra acabar com esse negócio.
Lock de arquivos é ruim, muito ruim! Já trabalhei assim a muitos e muitos anos atras, e sei que a coisa não funciona.
Ainda bem que isso foi considerado ultrapassado à muito tempo atras.
Se você tem duas equipes distintas, e tem que “proteger” uma equipe da outra (como no caso de uma pessoa acima que tem problemas com consultores externos) use branchs.
E se você for usar branchs, fuja do CVS (alias, fuja do CVS sempre).
Sugestões:
:arrow: GIT
:arrow: Bazaar
:arrow: SVN
Onde vc’s trabalham tem consultoria externa metendo a mão em codigo tbm ?