Operações e Conceitos comuns dos sistemas de controle de versão

Existem conceitos e operações que são comuns para a maioria dos sistemas de controle de versões atuais. De acordo com Sink (2011), existem operações básicas ou conceitos, que podem ser implementados em um sistema de controle de versão, cada sistema implementa a sua maneira dentro de sua estrutura.

2.4.3.1 commit

O processo de commit, tem por função acometer as mudanças, que foram realizadas em um arquivo para o seu respectivo repositório, ainda, de acordo com Fogel (2007), é armazenar formalmente uma alteração no banco de dados do sistema de controle de versão. Ainda cada commit pode carregar uma mensagem chamada de log message, que serve para informar o motivo da operação. Sato (2014, p.129) afirma que o commit “agrupa os arquivos alterados com o autor da mudança e uma mensagem explicativa. Isso permite que você navegue no histórico do projeto e saiba quem mudou o quê, quando e porquê”.

2.4.3.2 pull or update

Conforme Fogel (2007), no processo de update ocorre a atualização do projeto local, de modo que as mudanças que foram incorporadas pelos commit de outros usuários ao repositório, são incorporadas para a cópia de trabalho local. Para Sink ( 2011), a operação atualiza a cópia de trabalho local, aplicando as alterações provenientes do repositório e realizando merging com as alterações realizadas na cópia de trabalho, quando existirem alterações.

2.4.3.3 push

Na compreensão de Folger (2007), a operação de push se dá através do repasse de alterações, do repositório local, onde os commits foram realizados para um repositório principal. Nos sistemas distribuídos, as alterações são submetidas para atualizar um repositório remoto. Nos sistemas centralizados, a operação de commit já replica as alterações para o repositório principal.

33 2.4.3.4 checkout e cópia de trabalho

Segundo Fogel (2007), o checkout é o processo de se obter uma cópia de um projeto a partir do repositório onde ele se encontra, a cópia criada é chamada de cópia de trabalho, que é uma árvore de diretórios e que contém todos os arquivos e metadados necessários para que, através do controle de versão, sejam realizadas todas a operações necessárias para se manter a sincronia com o repositório.

2.4.3.5 merge

A operação de merge é a fusão de dois branches de desenvolvimento. Para Sink (2011) é a convergência dos ramos de desenvolvimento que estão divergentes e a mesclagem através de um sistema de controle de versão torna a operação mais simples.

2.4.3.6 resolve

Sink (2011) afirma que em alguns casos o merge automático não pode resolver conflitos existentes entre branches, neste caso a prática de resolução de conflitos confere responsabilidade ao usuário humano, seja manipulando manualmente um arquivo ou informando como o SCV deve prosseguir.

2.4.3.7 lock

No entendimento de Sink (2011) a operação lock é a obtenção de exclusividade para alterar um arquivo. Ainda afirma que, é mais eficiente deixar a cargo do SCV, o gerenciamento da concorrência em arquivos de texto simples e para arquivos binários, que são mais complexos é útil a utilização do lock. Collins-Sussman (2008) diz que a operação deve “permitir que um usuário requeira programaticamente o direito exclusivo de modificar um arquivo no repositório” e que também é “um mecanismo para exclusão mútua entre os usuários para evitar submissões conflitantes.” (COLLINS-SUSSMAN, 2008, p. 54)

34 2.4.3.8 tag

Sink (2011) afirma que a tag é a marcação de um momento específico do repositório, ou do projeto com um rótulo significativo. Para Bar (2003) é a associação de um evento em um momento específico, possibilitando assim, recuperar o projeto como ele era no momento rotulado.

2.4.3.9 log

Considerando que um sistemas de controle de versão armazena e mantém no repositório as alterações, ou operações já realizadas. O log seria a operação que permite visualizar o registro dessas operações Sink (2011). O log “irá acompanhar a história e evolução do seu projeto[...]Para cada mudança, você terá um registro de quem a fez; porque a fez; quando fez;o que foi alterado” (O’SULLIVAN, 2009, p.2,tradução nossa)

2.4.3.10 create

“A operação create é usada para criar um novo repositório.[...]Quando você cria um novo repositório, seus SCV vai esperar que você diga algo para identificá-lo, tal como onde você quer que ele seja criado, ou qual nome deve ser utilizado.” (SINK, 2011, p.5)

2.4.3.11 add

A operação de adição em controles de versão é utilizada para indicar arquivos ou diretórios que devem ser adicionados ao repositório. Conforme explica Sink (2011), a operação de adição é utilizada quando se tem um arquivo ou diretório que ainda não está sob controle de versão e deseja adicionar ao repositório. Ainda complementa que a adição não é realizada imediatamente, ela é adicionada ao conjunto de alterações da cópia de trabalho.

2.4.3.12 edit

A edição de arquivos não é uma funcionalidade direta do SCV, Sink(2011) o usuário altera um arquivo como qualquer outro de seu sistema de arquivos e cabe ao SCV reconhecer que o arquivo foi editado e adicionar essas alterações ao conjunto de alterações.

35

2.4.3.13 delete

A operação de delete é utilizada quando se quer excluir um arquivo ou diretório do repositório, de maneira resumida Sink (2011) escreveu que quando se marca um item para exclusão, o controle de versão não simplesmente exclui o arquivo do repositório, o SCV cria uma nova árvore no repositório na qual o arquivo não existe, mas mantém uma revisão onde o arquivo existe. a exclusão não é realizada imediatamente, ela é adicionada ao conjunto de alterações da cópia de trabalho, apenas após o commit é lançada ao repositório.

2.4.3.14 diff

Sink (2011) diz que a operação diff mostra as alterações realizadas na cópia de trabalho, a operação é implementada de diversas maneiras, cada sistema do seu jeito. Na ferramenta Subversion por exemplo, o comando diff pode ser utilizado para comparar arquivos em diferentes revisões e Collins-Sussman afirma que:

Tendo terminado de fazer suas alterações, você precisa registrá-las no repositório, mas antes de fazer isso, é quase sempre uma boa ideia conferir exatamente que alterações você fez. Ao verificar suas alterações antes de dar commit, você pode criar uma mensagem de log bem mais adequada. Você também pode descobrir se não modificou um arquivo inadvertidamente, e então ter a oportunidade de reverter essas modificações antes de dar commit.(COLLIN-SUSSMAN, 2008, p.20)

2.4.3.15 revert

Considerando em resumo o entendimento de O’Sullivan(2009), Sink(2011) e Collins- Sussman(2008), a reversão é a operação em que, se desfaz alterações realizadas em uma cópia de trabalho, assim como qualquer operação que foi realizada e não enviada ao repositório

2.4.3.16 move

A operação move, ou mover Sink(2011) realiza a realocação de um arquivo ou pasta de um lugar para outro dentro da árvore do repositório, dependendo do sistema, a operação fica aguardando o commit para ser submetida ao repositório e na cópia local pode ser realizada de imediato.

36 2.4.3.17 rename

É uma operação simples, Sink(2011) diz que o conceito de renomear um arquivo ou pasta, é a simples operação de renomear um item, alguns sistemas implementam essa operação de maneira mais formal outros nem tanto. Assim como para a operação move, a operação rename fica pendente até o envio ao repositório, porém na cópia de trabalho local pode ser efetivada imediatamente.

2.4.3.18 head

Swicegood (2007,p.61,tradução própria) explica que "head é uma palavra chave que se refere ao commit mais recente." Thomas (2003,p.57,tradução própria) diz que o "head representa a versão mais recente no repositório". Bar(2003) diz que head é uma tag especial reservada para representar o topo da trunk e é no head que o diretório de trabalho se baseia.

2.5 SUBVERSION

O Subversion é um sistema de controle de versão gratuito e de código aberto. De acordo com Collins-Sussman (2011), o sistema pode ser utilizado para versionar qualquer conjunto de arquivos, desde códigos fontes de um projeto de desenvolvimento até um simples arquivo contendo uma lista de compras. Segundo o livro oficial da ferramenta, a empresa CollabNet, insatisfeita com a ferramenta CVS (Concurrent Version System), em 2000 iniciou, juntamente com Karl Fogel e Jim Blandy, que também já haviam começado a pensar numa nova ferramenta, o projeto para criação de um sistema de controle de versão. Segundo Collins- Sussman (2011), o projeto do Subversion teve como um dos objetivos, desenvolver um sistema semelhante ao CVS, porém sem as falhas deste, de fácil adaptabilidade e migração para os usuários do CVS. Em 2001 o Subversion se tornou auto-gerenciável, os desenvolvedores passaram a utilizar o próprio Subversion para gerenciar o código do projeto.