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 ?
Controle de versão cvs, source safe
F
27 Respostas
G
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…
F
Lock de fontes remotos?
pra que isso? Cada um que resolva seus conflitos =)
Prefiro muito mais um GIT ou Mercurial 
G
Como assim ?? E em casos de equipes de desenvolvimento trabalhando no mesmo fonte ??
F
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.
G
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”…
E
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.
G
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
F
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.
F
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!
J
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:
P
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.
M
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.
F
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 ?
E
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.
- Eufemismo para “são uns antas”.
P
Parece que o problema é de BIOS* mesmo.
*Bicho ignorante operando o sistema.
L
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
M
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.
A
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
F
Onde vc’s trabalham tem consultoria externa metendo a mão em codigo tbm ?
L
Olá
Onde vc’s trabalham tem consultoria externa metendo a mão em codigo tbm ?
Mais motivos para usar SCM distribuído. Use o git que é de graça, muita gente está usando e você consegue tirar dúvidas facilmente.
Outra coisa: não se esqueça de que o sistema de controle de versões faz parte do sistema de entregas contínuas que deve ser o objetivo de todas as equipes de desenvolvimento. Então escolha seu SCM que funcione também com seu servidor de integração contínua.
Por fim obtenha um consenso na equipe sobre qual a melhor política de uso no dia a dia do SCM. Talvez um dia eu ainda blogue sobre isto que acho muito mais importante e difícil do que a escolha entre o Git, Mercurial, Perforce ou talvez o BitKeeper.
[]s
Luca
F
Existe algum client de git-svn pra windows? aqui na empresa usamos svn, mas gostaria de usar o git para depois mostrar o resultado
R
http://code.google.com/p/tortoisegit/
O Tortoise é uma opção embora a maioria dos usuários do git usem ele via linha de comando mesmo.
Eu particularmente já tentei utilizar o git pelo Eclipse (via plugin) mas desisti no mesmo dia pois já tinha me acostumado a usá-lo via linha de comando.
A única interface gráfica que uso esporadicamente para git é o gitk.
F
http://code.google.com/p/tortoisegit/
O Tortoise é uma opção embora a maioria dos usuários do git usem ele via linha de comando mesmo.
Eu particularmente já tentei utilizar o git pelo Eclipse (via plugin) mas desisti no mesmo dia pois já tinha me acostumado a usá-lo via linha de comando.
A única interface gráfica que uso esporadicamente para git é o gitk.
na verdade não quis me referir a um client grafico, eu gosto mais de trabalhar na linha de comando =P, agora pesquisando descobi que o msGit, tem suporte, mas é git svn não git-svn como no Linux auhauhuhaa.
Não sabia que o tortoise tinha pra git tbm ehehhe.
R
merge, sim :!:
lock, não.
M
CVS eu usava o WinCVS. Pro Mercurial não encontrei um cliente gráfico que eu agradasse, daí desisti e fui pro Subversion, mas só uso ele integrado ao Netbeans, também não achei um cliente gráfico que conseguisse configurar repositórios remotos via https.
F
http://code.google.com/p/tortoisegit/
O Tortoise é uma opção embora a maioria dos usuários do git usem ele via linha de comando mesmo.
Eu particularmente já tentei utilizar o git pelo Eclipse (via plugin) mas desisti no mesmo dia pois já tinha me acostumado a usá-lo via linha de comando.
A única interface gráfica que uso esporadicamente para git é o gitk.
Aqui todos os desenvolvedores usam o GIT via linha de comando mesmo. Só que os designers usam windows e são meio resistentes à linha de comando (talvez pelo fato de serem designers hehe), aí eles utilizam o tortoise git (que eu acho uma bosta), mas até o momento vem suprindo as necessidades.
W
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.
Criado 30 de agosto de 2010
Ultima resposta 30 de ago. de 2010
Respostas 27
Participantes 14