Agradeço, pelo link...muito interessante.
Mas ocorre que quando você esta trabalhando com manutenção e as
tarefas são divididas, muitas vezes
termos que fazer trabalhos conjuntos em cima do mesmo arquivo e/ou
no mesmo ponto, principalmente
quando você trabalha com integração de sistemas.
E ai é que vem o diferencial do SS em relação ao CVS...é mais
simples e seguro, simplismente fecha o acesso a terceiros.
Abraços, Silvio.
P.S.: O problema de desenvolver uma aplicação não esta no agora, mas
no DEPOIS !
-----Mensagem original-----
De: Felipe Leme [mailto:[EMAIL PROTECTED]
Enviada em: Tuesday, June 24, 2003 10:46 AM
Para: [EMAIL PROTECTED]
Assunto: Re: RES: [java-list] Re: to be EJB or not to be
On Monday 23 June 2003 08:31 am, SILVIO AMERICO GARCIA CICOTI wrote:
> Será que eu sou idiota, ou estou usando o CVS de forma errada
Você está usando o CVS de forma errada.
> Porquê toda vez que vou usar um arquivo tal para dar manutenção
> tenho que avisar meu colega do lado: "- olha cara, se você
> for mexer no arquivo tal...esta comigo viu !!!" ISSO É HORRIVEL !!!
CVS significa "Concurrent Version System". Ou seja, é um sistema planejado
para as pessoas acessarem os arquivos concorrentemente. Você pode ter um
arquivo grande com 2 pessoas modificando o arquivo em partes diferentes que
o
CVS fará o merge automático das mudanças. Agora, se as 2 pessoas estão
mexendo simultaneamente na mesma parte do arquivo, realmente dará conflito.
Fica aí a pergunta: a falha é do CVS por fazer o merge ou do gerenciamento
do
projeto, onde 2 pessoas editaram o mesmo recurso ao mesmo tempo?
Felipe
PS: uma boa fonte de informação sobre o CVS é o CVS Book
(http://cvsbook.red-bean.com/cvsbook.html). Por exemplo:
To understand what this has to do with facilitating collaboration, we'll
need
to take a closer look at the mechanism that CVS provides to help numerous
people work on the same project. But before we do that, let's take a look at
a mechanism that CVS doesn't provide (or at least, doesn't encourage): file
locking. If you've used other version control systems, you may be familiar
with the lock-modify-unlock development model, wherein a developer first
obtains exclusive write access (a lock) to the file to be edited, makes the
changes, and then releases the lock to allow other developers access to the
file. If someone else already has a lock on the file, they have to "release"
it before you can lock it and start making changes (or, in some
implementations, you may "steal" their lock, but that is often an unpleasant
surprise for them and not good practice!).
This system is workable if the developers know each other, know who's
planning
to do what at any given time, and can communicate with each other quickly if
someone cannot work because of access contention. However, if the developer
group becomes too large or too spread out, dealing with all the locking
issues begins to chip away at coding time; it becomes a constant hassle that
can discourage people from getting real work done.
CVS takes a more mellow approach. Rather than requiring that developers
coordinate with each other to avoid conflicts, CVS enables developers to
edit
simultaneously, assumes the burden of integrating all the changes, and keeps
track of any conflicts. This process uses the copy-modify-merge model, which
works as follows:
1. Developer A requests a working copy (a directory tree containing the
files that make up the project) from CVS. This is also known as "checking
out" a working copy, like checking a book out of the library.
2. Developer A edits freely in her working copy. At the same time, other
developers may be busy in their own working copies. Because these are all
separate copies, there is no interference - it is as though all of the
developers have their own copy of the same library book, and they're all at
work scribbling comments in the margins or rewriting certain pages
independently.
3. Developer A finishes her changes and commits them into CVS along with
a
"log message", which is a comment explaining the nature and purpose of the
changes. This is like informing the library of what changes she made to the
book and why. The library then incorporates these changes into a "master"
copy, where they are recorded for all time.
4. Meanwhile, other developers can have CVS query the library to see if
the
master copy has changed recently. If it has, CVS automatically updates their
working copies. (This part is magical and wonderful, and I hope you
appreciate it. Imagine how different the world would be if real books worked
this way!)
As far as CVS is concerned, all developers on a project are equal. Deciding
when to update or when to commit is largely a matter of personal preference
or project policy. One common strategy for coding projects is to always
update before commencing work on a major change and to commit only when the
changes are complete and tested so that the master copy is always in a
"runnable" state.
Perhaps you're wondering what happens when developers A and B, each in their
own working copy, make different changes to the same area of text and then
both commit their changes? This is called a conflict, and CVS notices it as
soon as developer B tries to commit changes. Instead of allowing developer B
to proceed, CVS announces that it has discovered a conflict and places
conflict markers (easily recognizable textual flags) at the conflicting
location in his copy. That location also shows both sets of changes,
arranged
for easy comparison. Developer B must sort it all out and commit a new
revision with the conflict resolved. Perhaps the two developers will need to
talk to each other to settle the issue. CVS only alerts the developers that
there is a conflict; it's up to human beings to actually resolve it.
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
***** Internet E-mail Confidentiality Footer *****
"Esta mensagem pode conter informações privilegiadas e/ou confidenciais de
propriedades da BCP Telecomunicações. Caso voce não seja o destinatário ou
pessoa autorizada a recebe-la não poderá utiliza-la de forma alguma. Cópia,
revelação ou quaisquer outras ações baseadas nestas informações não são
autorizadas. Se voce recebeu esta mensagem de forma equivocada, por favor
informe o emissor imediatamente respondendo a este email e em seguida
eliminando-o. Agradecemos sua cooperação."
"This message may contain confidential and/or privileged information belong
to BCP Telecomunications. If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy, disclose or take any
action based on this message or any information herein. If you have received
this message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
