Bem, respondo um pouco tarde, mas ainda vale....
Como eu disse no e-mail anterior (veja abaixo), "O CVS n�o tem o conceito de lock como dos outros sistemas de vers�o", vou detalhar
exatamente o que quis dizer.
Em outros sistemas de vers�o (vou cham�-lo SV) basta um comando (normalmente checkout), para que ele libere o arquivo local para edi��o (rw) e marque no reposit�rio central que o desenvolvedor X
reservou o arquivo (lock-modify-commit). Se outro desenvolvedor quiser editar j� ver� que o arquivo est� em edi��o (lock) e reservado para outro desenvolvedor.
No CVS pode-se usar o cvs edit (que ir� apenas marcar que o arquivo est� em edi��o pelo desenvolvedor X) e se algu�m quiser tamb�m poder� edit�-lo sem saber que o arquivo j� est� sendo editado pelo
desenvolvedor X, mas que pode ser verificado pelo cvs editors. (Algumas vezes j� presenciei que mesmo que eu fa�a um commit, a marca��o de edi��o ainda permanece).
O CVS � capaz de fazer lock (eu _n�o_ disse que n�o fazia, apenas disse que _�_ diferente dos SV do mercado).
Mas o esquema de lock do CVS n�o � algo do tipo lock-modify-commit (SV de mercado fazem assim: PVCS, CLEARCASE, etc.), o desenvolvedor tem de verificar se o arquivo est� em lock ou n�o (1 opera��o), e depois pedir a edi��o (2a opera��o). � poss�vel editar sem pedir edi��o - cvs edit - ao realizar um checkout rw.
O lock no CVS n�o � t�o intuitivo como o dos outros SV. Mais de 1 passo � necess�rio para usar o CVS usando conceitos de lock e m�ltiplos desenvolvedores: cvs admin -l para lock e cvs edit para marca��o de edi��o, e se outros desenvolvedores _tem_ de realizar uma query no CVS para saber se o arquivo est� sendo em edi��o por outras pessoas. E o desenvolvedor que efeutou o commit _deve_ remover o lock (cvs admin -u) para liberar o arquivo (2 passos).
E o lock do CVS tamb�m n�o tem muitas vantagens, pois se eu efetuar um commit em um arquivo que j� cont�m lock, eu serei avisado, e terei de atualizar a minha c�pia local (cvs update) com a existente no CVS e depois efetuar um commit.
Esse � o mesmo comportamente sem lock, se eu efetuar commit em um arquivo com uma revis�o mais atual do que a minha c�pia local, eu terei (como o lock) de realizar a atualiza��o local e depois commit.
Na documenta��o do CVS consta o seguinte (na se��o "Multiple developers":
This is not as nicely integrated into CVS as the watch features,
described below, but it seems that most people with a need for
reserved checkouts find it adequate. It also may be possible to use
the watches features described below, together with suitable
procedures (not enforced by software), to avoid having two people edit
at the same time.
Para quem _usa_ efetivamente o CVS, nota que poucas ferramentas oferecem o recurso de lock (cvs admin -l), e mesmo o WinCVS n�o oferece esta funcionalidade na vers�o mais atual (em uma vers�o que usei em 2001 tinha o icone da chave que representava o lock/unlock).
Em algumas partes do e-mail, fui um pouco redundante, mas o objetivo foi o de explicar detalhadamente o conceito de lock do CVS em compara��o com outros SV.
][s
Claudio Miranda
Paulo Silveira escreveu, On 15/1/2003 13:01:
Ola Claudio e pessoal
existe SIM como lockar arquivos no CVS, como em todos os outros versioning systems
procure pela opcao -l, ele locka uma versao de um arquivo, e apenas voce podera commitar ele a partir daquele momento, ateh que voce solte o lock
vale a pena salientar que LOCKAR (ou reserved checkout) � uma maneira muito infeliz de se trabalhar em conjunto, sendo muito menos produtivo que encarar os merges.
obrigado
======================
Paulo Eduardo Azevedo Silveira
Grupo de Usu�rios Java
http://www.guj.com.br/
On Wed, 15 Jan 2003 11:46:45 -0200, Claudio Miranda <[EMAIL PROTECTED]> escreveu :
De: Claudio Miranda <[EMAIL PROTECTED]>sabe como ?
Data: Wed, 15 Jan 2003 11:46:45 -0200
Para: [EMAIL PROTECTED]
Assunto: Re: RES: [enterprise-list] CVS
Como disse na minha mensagem anterior,
O CVS n�o tem o conceito de lock como dos outros sistemas de vers�o, pois se algu�m "editar" um arquivo versionado, ir� ficar apenas marcado, e a outra pessoa que quer editar o arquivo n�o receber� nenhuma notifica��o se quiser editar o mesmo arquivo, isso s� ser� feito se a 2a pessoa quiser "ver" (cvs watch) quem est� em fase de edi��o. Enquanto os outros sistemas de vers�o n�o deixam a 2a pessoa simplesmente editar, mas dizer explicitamente que quer editar mesmo que algu�m j� esteja fazendo isso.
][s
Claudio Miranda
Flavio Carvalho escreveu, On 14/1/2003 10:39:
Ola',
Ok, mas acho q ambos sao uteis - tanto o lock qto o merge. Acontece q nao consigo fazer um lock no CVS. Vc
[]s, FR.-----Mensagem original----- De: Fl�vio Leite [mailto:[EMAIL PROTECTED]] Enviada em: ter�a-feira, 14 de janeiro de 2003 09:08 Para: [EMAIL PROTECTED] Assunto: RES: [enterprise-list] CVS Opa... Opa... Opa... N�o � bem assim com o CVS n�o precisa ficar comunicando quem esta mexendo em determinado arquivo. As primeiras vers�es do CVS era baseada em lock-file e as mais recentes evoluiram para merges multiplos, ou seja, duas ou mais pessoas podem trabalhar no mesmo arquivo simultaneamente e o CVS se encarrega de fazer um merge multiplo no final se ocorrer concorrencia na mesma linha � liberado o merge manual ai sim o time precisa se comunicar e saber qual a linha a ser persistida. Muitos autores de teorias sobre sistemas de controle de vers�o e concorrencia de c�digo colocam como caracteristica fundamental para definir um sistema destes o lock-file. Por�m creio que as vers�es mais recentes destes ir�o pender mais para o merge multiplo. []s, Fl�vio.
--------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
