2. Entendendo o Funcionamento do VCS/SCM
Para entendermos os itens três e quatro deste artigo, precisamos primeiro nos debruçar no que diz respeito ao funcionamento de um sistema de controle de versão, ou seja, devemos explanar os conceitos básicos relacionados ao modelo apresentado.
O controle de versionamento é basicamente dividido em dois segmentos: o repositório, que é responsável pelo armazenamento das informações e a área de trabalho (Desktop). O repositório como havia descrito acima, é responsável pelo armazenamento das informações relacionadas ao projeto, em modo persistente no sistema de arquivo escolhido, ou até mesmo em um banco de dados. Nele será guardado todo o histórico de desenvolvimento do projeto e registrado também qualquer tipo de modificação realizada nos arquivos nele alocados.
O responsável pelo desenvolvimento do documento nunca trabalha diretamente nos arquivos do repositório, ele deve antes obter em sua área de trabalho uma cópia local, também chamada de cópia de trabalho (Working Copy) que contém a copia da ultima versão de cada arquivo do projeto e esta deverá ser monitorada para identificar qualquer tipo de alteração realizada. Essa área geralmente fica isolada das demais. A comunicação e sincronização entre o repositório e a área de trabalho se dão por duas operações distintas: commit e update, como demonstrado na figura abaixo:
Figura 1: topologia básica de um sistema para controle de versão.
O commit é responsável por submeter um pacote contendo uma ou mais modificações realizadas durante o desenvolvimento na área de trabalho que é a origem, para seu destino que é o repositório. O update por sua vez faz o trabalho proporcionalmente inverso, isto é, ele envia uma cópia de trabalho da ultima versão estável contida no repositório para a área de trabalho do desenvolvedor. Cada operação de commit gera uma nova revisão no repositório, registrando sempre todas as modificações realizadas, data e autor. Criando uma alusão a operação, é como se uma revisão fosse uma “fotografia” de todos os arquivos e diretórios em um determinado tempo da evolução do projeto. Essas “fotografias” de tempos passados são armazenadas no repositório e podem ser analisadas ou restauradas sempre que for desejado e o conjunto dessas revisões é justamente o que chamamos de histórico do projeto.
Podemos subdividir o sistema de controle de versão basicamente em dois tipos, de acordo com a maneira que cada um deles garante o controle e o gerenciamento do seu repositório: centralizado e distribuído. Nos CVS centralizados as mudanças são feitas para um repositório central e único, ao contrário dos distribuídos, onde os desenvolvedores trabalham diretamente no próprio repositório.
Então agora podemos dizer que, tanto o controle de versionamento centralizado quanto o distribuído basicamente funcionam sob os repositórios e as áreas de trabalho. A distinção está justamente em como cada uma dessas revisões estão adornadas no processo como um todo.
Podemos subdividir o sistema de controle de versão basicamente em dois tipos, de acordo com a maneira que cada um deles garante o controle e o gerenciamento do seu repositório: centralizado e distribuído. Nos CVS centralizados as mudanças são feitas para um repositório central e único, ao contrário dos distribuídos, onde os desenvolvedores trabalham diretamente no próprio repositório.
Então agora podemos dizer que, tanto o controle de versionamento centralizado quanto o distribuído basicamente funcionam sob os repositórios e as áreas de trabalho. A distinção está justamente em como cada uma dessas revisões estão adornadas no processo como um todo.
Download:
GIT: Controle de Versões Distribuído para Projetos de Software
0 Response to "2. Entendendo o Funcionamento do VCS/SCM"
Postar um comentário