Disciplina: Gerência de Projetos Professor: Leonardo Murta
IV – Lista de exercícios 1 – De acordo com as sentenças abaixo, defina quais são verdadeiras e quais são falsas, justificando sua resposta: a) O armazenamento num repositório baseado em forward delta delta é útil quando o desenvolvimento depende da recuperação constante de versões iniciais do sistema. R: Verdadeiro. A política de armazenamento baseado em forward delta delta armazena a primeira versão integralmente no repositório, e seus deltas deltas em seguida, até a versão mais atual. b) Numa estratégia de ramificação baseada em customizações somente o ramo de integração é manipulado (dica: ver slides sobre sobre estratégias de ramificação do curso de GC). R: Falso. Tanto os ramos de customização quando o de integração são manipulados. Entretanto, quando se tem uma nova versão no ramo de integração, as alterações presentes nesta versão são passadas aos ramos de customização, que por consequência terão novas versões. Os ramos de customização podem ter novas versões sem que o ramo de integração tenha sido atualizado, quando bugs nestas customizações são corrigidos ou novas funcionalidades específicas a estas atualizações são implementadas. c) O processo de auditoria é realizado após a liberação do produto, visando analisar se este foi corretamente implantado. R: Falso. O processo de auditoria é realizado para verificar se o software atende as especificações e não possui erros, sendo realizado antes da entrega/liberação do produto. d) A política pessimista de controle de versão visa evitar conflitos físicos em junções. R: Verdadeiro. A política pessimista apresenta meios para que dois usuários não alteram um mesmo item de configuração concorrentemente, evitando assim problemas que podem ocorrer na junção de versões. Porém, vale enfatizar que esta política evita somente conflitos físicos (em arquivos). 2 – Quais situações podem ocorrer no momento da junção de duas versões de um mesmo arquivo? Quais estratégias podem ser utilizadas para resolver estes problemas e que aspectos devem ser considerados durante a junção? R: Durante o processo de merge, podem ocorrer 2 situações: os arquivos podem ter sido modificados em partes distintas e os arquivos podem ter sido modificados em partes iguais. No primeiro caso, uma simples união dos arquivos resolverá. Quando os
arquivos possuem conflito no mesmo trecho, o processo de junção torna-se mais complicado, uma vez que precisamos analisar o contexto antes de realizar a junção. Entretanto, a sintaxe e a semântica do arquivo devem ser consideradas ao juntar arquivos. Algoritmos comumente utilizados não levam em conta estes aspectos, e é possível que mesmo que a junção ocorra com sucesso, erros ocorram. Por este motivo não se recomenda que a junção seja realizada unicamente por um sistema automatizado, mas conferida por um ou mais membros da equipe. 3 – Sabendo de seus conhecimentos em Gerência de Configuração adquiridos na disciplina de Engenharia de Software II, uma empresa de software o contratou para criar um sistema de controle de versão próprio. Quais as características desta empresa devem ser consideradas quando se projeta este sistema de controle de versão em quais aspectos do sistema de controle de versão estas características influenciam? R: No projeto deste sistema de controle de versão, características como a existência de equipes que trabalhem de forma distribuída (como filiais), a forma de trabalho da equipe (se existem pessoas que trabalham em um mesmo arquivo frequentemente), o formato dos projetos (se existe um projeto somente ou vários projetos que serão armazenados no mesmo repositório), a frequência com que versões antigas do projeto são acessadas e a forma de realizar alterações podem influenciar em características como topologia, controle de concorrência, forma de numerar versões, tipo de armazenamento e organização de ramos, respectivamente. 4 – Pesquise uma ferramenta de controle de versão existente (exceto o Subversion) e descreva qual a topologia utilizada, de que forma ela identifica versões, de que forma ela armazena versões e se (e como) ela trabalha com ramos. R: A título de exemplo, analisemos duas ferramentas: Git e Mercurial: Git: O Git é um sistema de controle de versão baseado na topologia distribuída, onde cada usuário possui um espaço de trabalho junto com o repositório local, sendo que este último pode ser “puxado” por outros usuários. O Git armazena versões “completas”, ou snapshots do repositório. Entretanto, ele cria links para os arquivos que não foram alterados desde a última versão, de forma transparente ao usuário. Assincronamente, o Git compacta o repositório, criando delta entre os arquivos. O Git armazena um hash do repositório em cada versão, para identifica-lo. Git trabalha com ramos, criando ponteiros que identificam estes ramos, os quais apontam para uma determinada revisão. Para identificar com qual ramo estamos trabalhando, um ponteiro HEAD é utilizado.
Mercurial:
O Mercurial é um sistema de controle de versão com topologia distribuída. No Mercurial, arquivos e informações sobre estes e suas versões são armazenados separadamente. A estrutura que agrega dados e arquivos de uma versão é chamada de revlog . Para armazenar versões de um arquivo, é utilizado o mecanismo de reverse delta. A versão mais atual é completa, e o conjunto de alterações para tornar uma versão mais nova em uma ou mais versões antigas é armazenado. Porém, ele também armazena uma versão completa a cada número específico de versões, de forma a agilizar a recuperação de versões mais antigas. Para numerar versões, o Mercural armazena tanto uma numeração sequencial para cada versão, computado no âmbito local, quanto um hash desta versão. Com relação a ramos, o Mercurial permite a criação de ramos, onde nomes identificam estes ramos. Podem ser criados ramos diretamente (pelo comando branch) ou indiretamente, quando clonamos um repositório.
