Exatamente isso João... O mais complicado, em termos gerais, vai ser doutrinar
o pessoal e implementar/implantar o servidor e os clientes ( mas existem quilos
e quilos de tutoriais na net pra me ajudar ) e essa doutrina cabe ao meu colega
( nem é um cliente pois nem vou cobrar pelo serviço... )
Alem do mais queria aproveitar essa mensagem para agradecer a todos que
compartilharam de seu ( escasso ) tempo me ajudando a esclarecer e entender a
aplicação de um controle de versões para situações onde não se está controlando
código-fonte.
Obrigado mesmo, amigos!
Atte,
Ricardo Cardoso.
--- Em sex, 25/7/08, Joao Morais <[EMAIL PROTECTED]> escreveu:
De: Joao Morais <[EMAIL PROTECTED]>
Assunto: Re: [delphi-br] [ OFF-TOPIC ] Controle de Versões
Para: delphi-br@yahoogrupos.com.br
Data: Sexta-feira, 25 de Julho de 2008, 7:35
Ricardo César Cardoso wrote:
> É isso que eu pensei e argumentei com o meu camarada. Mas garantiu ( e pela
> experiencia que tive nessa área pude confirmar ) que nunca vai acontecer de
> dois desenhistas modificarem um desenho ao mesmo tempo. Mas pode acontecer de
> um desenhista pegar um desenho pra modificar e não notificar o restante da
> equipe que ele está trabalhando naquele desenho. O que acontece? O cliente
> liga furioso perto do horário do almoço; o patrão corre pro primeiro
> desenhista que encontra e chicoteia o coitado pra fazer o mais rápido
> possível; e o cara vai e faz. E acontece a perda de controle pois o trabalho
> que o primeiro desenhista estava fazendo no desenho é perdido.
>
> Com o lock do Subversion acredito que cada vez que se tente abrir este
> desenho uma notificação é lançada e voilà. Já se sabe que alguém está
> trabalhando no desenho. E quando o desenhista termina seu trabalho ele libera
> ( seria um checkout? ) o desenho para que se necessário outros possam alterar
> o desenho.
>
> Portanto, nesses casos não trabalharei com merge. O modelo de trabalho não
> comporta essa situação.
Conflito no Subversion possuem duas situações que são as seguintes:
1. Sem lock: Dois ou mais usuários mexem no arquivo. O primeiro que vier
a gravar vai conseguir, do segundo em diante que tentar gravar, o
Subversion vai informar que a revisão deles está desatualizada. Quando
fizerem um checkout para atualizar, vai dar conflito no arquivo. Como
não é texto, o svn não tentará fazer um merge e ficará uma marca de
conflito. O usuário que fez o checkout terá, na máquina dele, o arquivo
do repositório e o arquivo que ele mexeu, para escolher qual é o certo.
2. Com lock: um usuário que estiver mexendo em um arquivo poderá fazer o
lock desse arquivo. Isto significa que quem tentar *gravar* esse arquivo
de volta no repositório receberá uma mensagem de que ele está bloqueado.
Neste caso é uma garantia de que quem fez o lock irá conseguir gravar
depois, independente do que aconteça.
O que você pode explicar para o seu cliente:
Quem quiser garantia de que vai conseguir *gravar* uma alteração, tem
que fazer um lock. O lock não é obrigatório, o máximo que pode acontecer
em não usá-lo é um conflito na hora de gravar a alteração. Então ele
confere no repositório pra saber quem fez a gravação anteriormente, faz
um checkout e recebe a versão do outro cara, escolhe qual a correta: se
for a dele, arruma a sua revisão e faz um checkin. Se for a do outro,
faz um revert. Se for um merge, ele abre as duas versões no autocad,
coloca as alterações do outro no seu próprio arquivo e grava o seu arquivo.
Simples assim.
Joao Morais
_
Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua
cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses
[As partes desta mensagem que não continham texto foram removidas]
