07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Aula 1

VANTAGENS E DESVANTAGENS DOS REPOSITÓRIOS

CENTRALIZADOS
Imprimir

Revision Control System (RCS): histórico, ciclo de trabalho, operações, características, interface,
status técnico; Concurrent Version System (CVS): histórico, ciclo de trabalho, operações,
características, interface, status técnico; Subversion (SVN): histórico, ciclo de trabalho, operações,
características, interface, status técnico.

19 minutos

INTRODUÇÃO
Nesta aula conheceremos algumas das vantagens e desvantagens dos sistemas de controle de versão
centralizados a partir dos sistemas Revision Control System (RCS), Concurrent Version System (CVS), Subversion
(SVN) e Microsoft Visual SourceSafe.

Apresentaremos o histórico, o ciclo de trabalho, as operações, as principais características, a interface gráfica e

o status técnico desses sistemas de controle de versão centralizados. É fundamental entender as principais
funções dessas ferramentas.

Convido você a estudar este material de modo empenhado, pois foi elaborado de forma cuidadosa para ajudá-
lo em seu percurso de estudos e profissional.

Bons estudos!

REVISION CONTROL SYSTEM (RCS): HISTÓRICO, CICLO DE TRABALHO,

OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O Revistion Control System (RCS), ou sistema de controle de versão de revisão, foi desenvolvido por Walter F.
Tichy na universidade de Purdue no início dos anos 1980. O design do RCS é um aprimoramento de seu
predecessor Source Code Control System (SCCS). As melhorias incluem uma interface de usuário mais fácil e um
armazenamento aprimorado de versões para recuperação mais rápida de informações. É um exemplo de
sistema de controle de versão centralizado.

Uma das principais características do RCS é que ele opera por meio de um conjunto de comandos Unix, isto é,
uma lista de comandos do sistema operacional Linux. Outra operação importante do sistema é gerenciar
grupos de revisão, que são conjuntos de documentos de texto, chamados de revisões, que evoluíram umas das
outras. Uma nova revisão é criada editando manualmente sobre uma já existente. Outra função do RCS é
organizar os arquivos em formato de árvore, além de oferecer recursos para mesclar atualizações com
modificações do cliente com uma identificação automática. Essa identificação é o 'carimbo' de revisões e
configurações com marcadores únicos, semelhantes a números de série, informando aos desenvolvedores de
software qual configuração está diante deles, resultando em um pacote poderoso para controle de versão.

É possível visualizar graficamente o ciclo de trabalho do RCS por meio da criação de revisões e versões.
Suponha que uma árvore tenha cinco revisões agrupadas em duas versões, conforme ilustrado na Figura 1.
Desta forma, a última da versão 1 está em operação nas instalações do cliente, enquanto a versão 2 está em
desenvolvimento ativo.
[Link] 1/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Figura 1 | Exemplo de árvore de revisões e versões

Fonte: Tichy, 1984.

Para economizar espaço, o RCS armazena as revisões na forma de deltas, ou seja, com diferenças entre as
revisões, e a interface do usuário oculta isso completamente. Os triângulos apontados para a esquerda e para a
direita representam deltas reversos e diretos, respectivamente. Você pode notar também, na Figura 2, os
branches nos itens [Link] e [Link], isto é, ramificações ou quebras na linha de desenvolvimento criando novos
caminhos. Essa ramificação é muito utilizada para realizar manutenções evolutivas e correções nos softwares.

Figura 2 | Árvore de revisão com deltas reversos e diretos

Fonte: Tichy, 1984.

Esse sistema de controle de versões utiliza os modelos de comandos checkin e checkout. Isso quer dizer que um
desenvolvedor inicia o trabalho executando o comando checkout, realizando uma cópia do projeto no local de
trabalho para concretizar as alterações desejadas, e ao finalizar, executa o comando checkin ou commit, que é
encarregado por enviar tais modificações ao repositório.

Uma das desvantagens do RCS é o método locking que impede o desenvolvimento paralelo, mas existem
formas que possibilitam o prosseguimento do trabalho de um projeto. Por exemplo, mesmo se uma revisão
estiver bloqueada, o desenvolvedor pode verificá-la, fazer checkin em um branch e mesclar as alterações; pode
descobrir quem está bloqueando o arquivo e pedir a essa pessoa que a libere; quebrar a fechadura, que deixa
um rastro bastante visível, nomeadamente um e-mail que é enviado automaticamente para o titular da
fechadura (TICHY, 1984).

VIDEOAULA: REVISION CONTROL SYSTEM (RCS): HISTÓRICO, CICLO DE

TRABALHO, OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O vídeo mostra como ocorre o processo de revisão em um RCS, desde a criação do arquivo, a edição, a
verificação, a confirmação e as alterações dele até o entendimento do que é a versão principal e as versões
experimentais.

Videoaula: Revision Control System (RCS): histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

[Link] 2/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

CONCURRENT VERSION SYSTEM (CVS): HISTÓRICO, CICLO DE TRABALHO,

OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
No histórico do Concurrent Version System (CVS) identificamos que foi um sistema de gerenciamento de
versões originalmente desenvolvido por Dick Grune, em 1986. No início, correspondia a um conjunto de
scripts shell do Unix. Em 1989 foi projetado e codificado na linguagem de programação C por Brian Berlinger e,
mais tarde, junto a Jeft Polk, introduziram módulos e suporte à geração de branches (ramificações) no CVS
(PAIVA; JUNQUEIRA; FORTES, 2002).

Você sabe quais são as operações básicas do CVS? Paiva, Junqueira e Fortes (2002, p. 3) identificam as
seguintes:

[Manutenção] de um histórico de todas as alterações feitas nos diretórios que são gerenciados. Com base
nesse histórico, o CVS pode mostrar a um desenvolvedor quando, por que e por quem uma alteração foi
feita.

[Armazenamento de] versões em um repositório central que mantém as cópias principais de todos os
arquivos que estão sob o gerenciamento de versões.

[Recuperação de] versões anteriores de arquivos eficientemente.

Permite que grupos de desenvolvedores controlem arquivos por meio da rede de forma transparente.

[Suporte ao] desenvolvimento paralelo, permitindo que mais de uma pessoa trabalhe em um mesmo
arquivo ao mesmo tempo.

[Fornecimento ao] acesso confiável aos diretórios a partir de máquinas hospedeiras (hosts) remotas
usando protocolos internet.

Permite adicionar, remover e alterar arquivos e diretórios do repositório.

Permite agrupar uma coleção de arquivos relacionados em módulos e, então, o módulo passa a ser
gerenciado.

O CVS apresenta como principais características o armazenamento de todas as informações sobre o controle
de versões em arquivos dispostos e contidos em uma hierarquia de diretórios conhecida como repositório.
Nele, o CVS provisiona todos os arquivos e diretórios controlados pelos sistemas de versões. Geralmente, os
usuários não acessam tais arquivos no repositório diretamente. Os desenvolvedores utilizam o comando
checkout para obter uma cópia dos arquivos em um diretório de trabalho e trabalhar neles. Quando terminam
de efetuar as modificações, enviam os arquivos novamente para o repositório, por meio do comando
commit. Desta maneira, o repositório contém quando e como foram feitas todas as mudanças efetuadas.
Lembrando: o repositório não é um subdiretório de um diretório de trabalho ou vice-versa. O repositório e o
diretório de trabalho estão em locais diferentes (PAIVA; JUNQUEIRA; FORTES, 2002).

O CVS realiza seu ciclo de trabalho pelos comandos checkout e commit, como descrito no parágrafo anterior, e
também por outros comandos, que são:

import: usado para incorporar diretórios ao repositório e também criar o repositório.

add: permite adicionar um novo arquivo ou diretório ao controle de versões.

annotate: possibilita visualizar as últimas modificações feitas em cada linha do arquivo especificado.

[Link] 3/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

diff: utilizado para comparar diferentes revisões de arquivos, isto é, permite conferir o arquivo no qual o
usuário está trabalhando com as revisões que lhe deram origem, mostrando as diferenças encontradas.

update: permite atualizar o diretório de trabalho do usuário, deixando a árvore de arquivos/diretórios igual
a do repositório. Isso ocorre quando o usuário faz checkout de um arquivo ou diretório enquanto outros
desenvolvedores podem estar trabalhando no mesmo diretório ou até no mesmo arquivo. Para isso,
aciona-se o comando update para conciliar o trabalho do primeiro usuário com as revisões enviadas ao
repositório desde a última execução do comando checkout ou update.

remove: utilizado para remover um arquivo do repositório.

release: útil para cancelar, de forma segura, o efeito do comando checkout (PAIVA; JUNQUEIRA; FORTES,
2002).

Ao analisar o status técnico, você verificará que pode ser executado em várias plataformas, como Unix, Linux e
demais sistemas POSIX, Windows, Macintosh e VMS, além de ter bastante documentação. Na Figura 3, observe a
interface do CVS pelo sistema operacional Windows.

Figura 3 | A interface do CVS pelo Windows

Fonte: CVSgui.

VIDEOAULA: CONCURRENT VERSION SYSTEM (CVS): HISTÓRICO, CICLO DE

TRABALHO, OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O vídeo tem o objetivo de chamar atenção sobre os caminhos de utilização do CVS e mostrar os principais
estados de uso de um arquivo nesse sistema de controle de versão.

Videoaula: Concurrent Version System (CVS): histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

[Link] 4/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

SUBVERSION (SVN) E MICROSOFT VISUAL SOURCESAFE: HISTÓRICO, CICLO DE

TRABALHO, OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
No processo histórico de desenvolvimento do Subversion encontramos um cenário em 2000, no qual, apesar
da ótima aceitação, o CVS apresentava erros críticos. Desta forma, a empresa norte-americana CollabNet, por
meio dos desenvolvedores Jim Blandy Karl Fogel, Ben Collins-Sussman, Brian Behlendorf e Jason Robbins
criaram o Subversion (SVN) para corrigir os erros do CVS, estratégia que foi bastante desaprovada por outros
desenvolvedores. Já em 2001, passou a ter o próprio código-fonte, e em 2009, foi integrante do projeto Apache
2010 (FREITAS, 2010).

Por meio do status técnico do Subversion (SVN), é possível perceber a adoção da licença Apache,
que possibilita o uso do código-fonte para o desenvolvimento de software proprietário, bem como software
livre e open source. Os clientes e servidores trabalham com os sistemas operacionais Unix, Windows e Mac OS
X. A interoperabilidade do Subversion é um fator favorável, pois existem plugins para ambientes integrados
de desenvolvimento (IDEs), como o Subclipse e o Subversive para o Eclipse, e o VisualSVN para o Visual Studio. O
SVN tem uma vasta documentação disponível (FREITAS, 2010).

Nas operações de repositório do SVN, o comando commit pode ser desconsiderado caso seja interrompido,
como em casos de queda de energia. Ele possui uma ferramenta que possibilita sua replicação. É uma
ferramenta de controle de versões que trabalha de forma centralizada, não tendo a funcionalidade de propagar
as mudanças. Para cumprir a função de clonagem, os colaboradores desenvolveram os componentes
SVNMirror e o SVNPusher.

O SVN define permissões de acesso para diferentes partes do repositório remoto por meio do protocolo HTTP.
Além do histórico de revisões por linha de um arquivo ou URL especificados, é possível obter informações do
autor e quando as modificações foram feitas. Para isso, o SVN cria um changeset com a lista de
arquivos alterados, autores, data e mensagem de log (FREITAS, 2010).

Uma característica essencial do Subversion é que ele consegue controlar as alterações realizadas na cópia de
trabalho que ainda não foram enviadas ao repositório. É possível acompanhar todo commit no SVN por envio
de uma mensagem de log, ou seja, o usuário pode descrever todas as alterações relativas àquele commit em
uma mensagem, que fica gravada no repositório. As mensagens de log são apresentadas ao conjunto
de mudanças. No SVN, o usuário tem duas opções: fazer checkout ou commit no repositório como um todo ou
checkout ou commit parcial, isto é, selecionando apenas o diretório desejado (FREITAS, 2010).

O Subversion é uma das ferramentas de controle de versões com o maior número de clientes baseados em
interface web. Dessa maneira, é possível navegar por meio da árvore e das várias revisões dos arquivos. A
Figura 4 apresenta a ferramenta Trac como um dos exemplos de interface web para o SVN.

Figura 4 | Trac Subversion

[Link] 5/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Fonte: Freitas (2010, p. 21).

No processo histórico do SourceSafe, visualizamos que foi originalmente criado por uma empresa da Carolina
do Norte chamada One Tree Software. Com a aquisição dessa empresa, a Mainsoft Corporation desenvolveu o
SourceSafe para Unix em cooperação com a Microsoft.

Uma das principais características do SourceSafe é operar como um sistema de controle de versões vendido
pela Microsoft junto com o pacote Microsoft Visual Studio. Ele tem as vantagens de se integrar com outras
ferramentas da Microsoft como o Visual [Link] e ter boa interface com o usuário. Suas operações básicas
são a centralização dos arquivos, o gerenciamento de acesso e o histórico das modificações. As principais
desvantagens dessa ferramenta são a dificuldade de gerenciar módulos externos, a má gestão das redes, a
lentidão na busca de versões anteriores no seu repositório e não possui versão nativa para Linux. Atualmente,
tal ferramenta está em desuso.

VIDEOAULA: SUBVERSION (SVN) E MICROSOFT VISUAL SOURCESAFE:

HISTÓRICO, CICLO DE TRABALHO, OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E
STATUS TÉCNICO
O vídeo apresenta alguns comandos básicos do Subversion e mostra detalhadamente o ciclo ou o fluxo de
trabalho do sistema de controle de versão.

Videoaula: Subversion (SVN) e Microsoft Visual SourceSafe: histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

ESTUDO DE CASO
Você gerencia uma equipe de desenvolvedores de uma empresa de pequeno porte. O projeto em que vocês
estão trabalhando exige a utilização de um sistema de controle de versão para melhorar o processo de
desenvolvimento e permitir uma gestão mais eficiente do código-fonte do projeto.

Devido ao baixo orçamento, vocês decidem qual é o melhor sistema de versionamento a ser utilizado. Além
disso, você propõe definir coletivamente o que deverá ser subversionado, isto é, a criação de diferentes versões
e quais serão os principais requisitos e passos para a instalação do SVN.

[Link] 6/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

RESOLUÇÃO DO ESTUDO DE CASO

Com as informações disponíveis, você e sua equipe compreendem que, devido ao baixo orçamento da empresa,
o Subversion é ideal, pois exige poucos recursos computacionais, oferecendo infraestrutura para os
desenvolvedores individuais e as pequenas empresas Com ele até mesmo um computador mais antigo, que não
está sendo usado, pode ser utilizado como servidor. Também é possível usar uma estrutura de discos
individuais de armazenamento, que resultam em um sistema robusto de versionamento e backup a um custo
muito mais baixo.

Os itens que devem ser subversionados ou criados em diferentes versões são: códigos-fontes, arquivos de
configuração, documentos e tudo o que não for gerado a partir desse material. Não devem ser versionados
itens que forem resultantes da compilação, como por exemplo, arquivos Python do tipo .pyc. É importante
lembrar que o controle de versão não é propriamente um backup, embora exerça este papel adicional durante
o desenvolvimento de um projeto.

A instalação pode ser realizada direto em uma máquina “servidora” ou por meio do SSH, ou seja, um Secure
Shell, que é um protocolo de rede criptográfico para operação de serviços de rede segura. A instalação é
simples, pois é utilizada apenas uma linha de comando. É bastante importante que o servidor tenha um
endereço fixo, pois isso facilita a conexão com ele. Por questões de segurança, é relevante que a troca de
informações entre o servidor e o cliente seja criptografada.

Para instalação do SVN, basta acessar o site do VisualSVN Server, fazer o download, seguir as instruções de
instalação, configurar o termo de licença e as ferramentas de administração, escolher a versão (preferencial
Standard) e definir um diretório para os repositórios.

Para cada novo projeto, é aconselhado ter um repositório só para ele, pois facilita o controle de acesso e o
gerenciamento do repositório. É necessário também definir quem poderá ter acesso a ele por meio da
identificação de usuário e senha. Além disso, é essencial garantir a inicialização automática.

Com base no levantamento das definições, você e sua equipe compreenderam que o uso do Subversion é ideal
pois oferece infraestrutura para as pequenas empresas. Além disso, oferece os requisitos e os passos simples
para a instalação, devendo essencialmente identificar os acessos dos usuários. Também foi estabelecido que os
itens a serem versionados são: códigos-fontes, arquivos de configuração, documentos e tudo o que for gerado a
partir deste material.

Resolução do Estudo de Caso

Para visualizar o objeto, acesse seu material digital.

 Saiba mais
No site [Link] você encontrará um livro em várias versões .pdf,
.html e .xml com várias informações técnicas, documentos e tutoriais do Subversion.

Aula 2

VANTAGENS E DESVANTAGENS DOS REPOSITÓRIOS

DISTRIBUÍDOS

[Link] 7/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Gerenciamento dos dados: principais atribuições; Práticas recomendadas para criar e gerenciar
repositórios de dados; Integração com outros softwares.

21 minutos

INTRODUÇÃO
Nesta aula você compreenderá algumas das vantagens e desvantagens dos sistemas de controle de versão
distribuídos a partir da ferramentas conhecidas, como BAZAAR, Mercurial, GNU arch, Monotone, Darcs e
Launchpad.

Apresentaremos o histórico, o ciclo de trabalho, as operações, as principais características, a interface gráfica e

o status técnico desses sistemas de controle de versão centralizados.

Convido você a ler e estudar este material que foi elaborado de forma cuidadosa para ajudá-lo em seu percurso
de estudos. Leia e releia o texto e faça suas anotações.

Bons estudos!

BAZAAR E MERCURIAL: HISTÓRICO, CICLO DE TRABALHO, OPERAÇÕES,

CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O BAZAAR é um sistema de controle de versão que auxilia no rastreamento do histórico do projeto ao longo do
tempo. Faz parte do projeto General Public License (GNU), sendo um software livre patrocinado pela Canonical.
Em seu histórico consta que foi criado em 2005 pelo desenvolvedor Martin Pool e lançado em 2007. Em 2017,
parte seu código-fonte foi incorporado ao projeto de software Breezy para possibilitar a migração de Python 2 e
3 e a eliminação do suporte para versões anteriores do Windows.

As principais características dele são:

A existência de uma comunidade grande e ativa de desenvolvedores.

O controle do repositório fica na raiz do projeto, em um diretório chamado .bzr.

A permissão de trabalho nos repositórios SVN, Git e Mercurial.

O foco na facilidade de uso.

O suporte a plugins (MACHADO, 2019).

Observe os principais conceitos e operações na Figura 1.

Figura 1 | Conceitos e operações no BAZAAR

Conceitos e
operações BAZAAR

repository Contém armazenamento de objeto para um ou mais branches.

branch A unidade fundamental de metadados de versão no BAZAAR.

[Link] 8/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Conceitos e
operações BAZAAR

workspace Estação ou espaço de trabalho.

checkout Um espaço ou uma estação de trabalho que não contém dados de objeto, apenas
metadados principais. Ele aponta para um branch que pode estar no sistema de arquivos
local ou em um host remoto. É responsável pelo envio de atualizações para esse branch,
fornecendo semântica "centralizada".

bound É uma filial.

branch Atualizado localmente no commit, mas, adicionalmente, atualiza automaticamente o branch

remoto ao qual está vinculado.

conflict Conflitos podem ocorrer ao adicionar arquivos ou diretórios.

Fonte: adaptado de Bazaar Explorer ([s.d.], [s.p.]).

No status técnico dessa ferramenta, por meio da sua documentação verifica-se que foi escrito em Python,
Pyrex e C. Sua última versão 2.7.0 foi lançada em fevereiro de 2016 e está disponível para os sistemas
operacionais Windows, Linus e OS X.

Verifique o ciclo de trabalho desse recurso por meio dos seus principais comandos mencionados na Figura 2.

Figura 2 | Comandos no BAZAAR

Figura 2 | Comandos no BAZAAR

Comandos BAZAAR

init Cria um novo branch.

init-repo Cria um novo repositório compartilhado.

clone Clona um repositório compartilhado que está em desenvolvimento.

branch Clona um branch, incluindo metadados e dados de objeto.

reset Oferece suporte parcial pelos comandos reverter e não confirmar.

revert Atualiza o cabeçalho do branch e/ou o conteúdo específico para a revisão especificada.

merge Mesclagens não são documentadas, e é possível mesclar diretamente de branches remotos.

push Desnecessário em checkouts e branches vinculados.

[Link] 9/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Comandos BAZAAR

pull Busca e avança (não pode fazer mesclagens não triviais).

status Verifica o estado em que se encontra um arquivo.

log Confirmações fora da linha principal são suprimidas, a menos que explicitamente solicitado.
Pelo fato de a mesclagem não ser confirmada automaticamente, a mensagem de confirmação
de mesclagem deve descrever com precisão o histórico do branch mesclado.

Fonte: adaptado de Bazaar Explorer ([s.d.], [s.p.]).

A interface gráfica do BAZAAR pode ser visualizada na Figura 3.

Figura 3 | Interface gráfica do BAZAAR

Fonte: adaptado de Bazaar Explorer ([s.d.], [s.p.]).

O Mercurial foi criado por Matt Mackall e lançado em 2005. Assim como o Git, foi adotado em muitos projetos
importantes, sendo um dos sistemas de controle de versão mais populares.

No status técnico, você constará que possui boa documentação disponível e um pacote completo para
instalação. No Windows, a instalação recomendada é pelo TortoiseHg, que já instala tanto o cliente de interface
gráfica quanto o Mercurial. Já para o Linux há vários pacotes de instalação (FREITAS, 2010).

Observe os principais conceitos e operações na Figura 4.

Figura 4 | Conceitos e operações no Mercurial

Comandos Mercurial

commit É atômico, ou seja, se a operação for interrompida, ela é desconsiderada e o repositório não
fica em um estado inconsistente. Pode ser restrito, usando gerenciamento de permissões, e
é acompanhado de uma mensagem de log.

hg-clone Clona um repositório.

[Link] 10/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Comandos Mercurial

hg-push Envia as alterações do repositório local para um remoto.

hg-pull Faz download das alterações.

hg-pull + hg- Faz download das alterações de outro repositório e um merge com a cópia do trabalho.
update

hg-diff O usuário pode analisar suas alterações com cautela antes de enviá-las ao repositório.

log O usuário pode descrever todas as alterações relativas a um commit em uma mensagem
que fica gravada no repositório. O Mercurial também permite apenas uma mensagem de log
para todo o conjunto de mudanças, não sendo possível que cada arquivo tenha uma
mensagem de log particular.

Fonte: Freitas (2010, p. 34).

As principais características do Mercurial são:

Possibilitar definir permissões tanto para o repositório como um todo quanto para diretórios e arquivos. O
controle dessas permissões pode ser feito por meio dos protocolos SSH e HTTP.

Registrar as revisões, quem realizou as alterações e quando elas foram feitas em um arquivo ou diretório.

Registrar changeset com um número de identificação chamado changeset ID e gravar todos os changesets
do repositório em um arquivo chamado changelog.

Ao apagar um arquivo, faz em seguida uma réplica idêntica à apagada, com o nome desejado.

Trabalhar com merge inteligente após operações de rename em um arquivo. Isso significa que se o nome
de um arquivo é alterado depois das modificações e, em seguida, é feito um merge entre o arquivo com
nome antigo e o com nome novo, o Mercurial consegue identificar que os dois são o mesmo arquivo e
realizar o merge corretamente (FREITAS, 2010, p. 35).

Veja na Figura 5 a interface do Mercurial por meio do Trac Mercurial.

Figura 5 | Trac Mercurial

[Link] 11/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Fonte: Freitas (2010, p. 36).

VIDEOAULA: BAZAAR E MERCURIAL: HISTÓRICO, CICLO DE TRABALHO,

OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O vídeo mostra apenas algumas comandos básicos para o uso do Mercurial. Além disso, apresenta o ciclo ou o
fluxo de trabalho dos usuários e desenvolvedores desse sistema de controle de versão.

Videoaula: BAZAAR e Mercurial: histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

LAUNCHPAD E GNU ARCH: HISTÓRICO, CICLO DE TRABALHO, OPERAÇÕES,

CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
A Launchpad é uma aplicação web que auxilia no desenvolvimento de software, particularmente software livre.
Este projeto teve o seu código-fonte foi disponibilizado em julho de 2009, é publicamente protegido pela licença
GNU e desenvolvido e mantido pela Canonical. Em agosto de 2009, já abrigava mais de 13000 projetos. O
ambiente de Launchpad permite que um desenvolvedor individual contribua com a comunidade em traduções,
no registro de erros e em códigos. Com isso, é possível participar do desenvolvimento de código aberto. Além
disso, verifica-se em seu status técnico que foi escrito em Python, usa o BAZAAR como repositório e possui
grandes projetos como MySQL (code hosting), Zope 3 (bug tracking), Inkscape (bug tracking). Sua versão mais
recente é a Launchpad 3.0 de 2009.

As principais características dessa ferramenta é o controle de um número de tarefas e conceitos importantes do

código aberto, que são:

Arquivamento e rastreamento de erros (tracking bugs) em pacotes e atualização de produtos.

Tradução de pacotes.

Gerenciamento de branches que elevam o universo de código aberto.

Gerenciamento do desenvolvimento e das liberações de distribuições Linux.

Fornecimento da distribuição, do produto, das pessoas e dos pacotes baseados nos itens acima
(MACHADO, 2019).

As três principais aplicações são:

Malone: para registro e gerenciamento de erros de softwares (bug tracker).

Rosetta: extremamente fácil para a realização de traduções, isto é, possibilita aos desenvolvedores um
período de transição no qual podem atualizar um software de aplicativo para “rodar” em um hardware
mais recente, "traduzindo-o" para ser executado em uma arquitetura diferente;

BAZAAR: para sistemas de controle de revisões.

Elaborado por Thomas Lord e Andy Tai, o software GNU arch é um sistema de controle de revisão distribuído,
parte do projeto GNU e licenciado sob a General Public License (GNU). É usado para controlar as alterações
feitas em uma árvore de código-fonte e para ajudar os programadores a combinar e a manipular as alterações

[Link] 12/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

feitas por várias pessoas ou em momentos diferentes. Sua grande desvantagem é a grande quantidade de
comandos. A partir de 2009, o status oficial do GNU arch foi considerado obsoleto e apenas correções de
segurança são aplicadas.

Suas principais características são:

Por ser um sistema de controle de versão descentralizado e distribuído, cada revisão armazenada usando-
o é identificável de forma única e global, e esse identificador pode ser usado em uma configuração
distribuída para mesclar facilmente ou selecionar manualmente alterações de fontes completamente
diferentes.

Disponibilização de uma cópia completa somente de leitura de um projeto em um repositório "oficial" via
HTTP e FTP; desta forma, os contribuidores são encorajados a fazer modificações e publicá-los em um
arquivo público (repositório) próprio, para que um desenvolvedor chefe possa mesclar manualmente os
conjuntos de alterações no repositório oficial.

Simulação do comportamento de sistemas de controle de revisão centralizados, no qual permite-se acesso

shell (SSH) ou acesso de gravação a um servidor, a usuários autorizados que se comprometam com um
servidor central (MACHADO, 2019).

As principais operações são feitas por meio de commits. Eles não são visíveis para todos os usuários até que
sejam concluídos. Caso sejam interrompidos antes disso, permanecem invisíveis e, então, são revertidos antes
do próximo commit. Tal ação é importante porque evita a corrupção do arquivo e das cópias retiradas de outros
usuários. Outra operação relevante é o rastreio de um conjunto de alterações (patches), ao invés de arquivos
individuais. Em cada conjunto de alterações encontra-se uma descrição da diferença entre uma árvore de
origem e outra. Sendo assim, é possível que um conjunto de alterações seja usado para produzir uma revisão a
partir de outra revisão. Desta forma, podemos dizer que tal ferramenta orienta suas operações por meio de um
conjunto de mudanças. Em seu ciclo de trabalho, há outros conceitos essenciais, como verificado na Figura 6.

Figura 6 | Conceitos de trabalho do GNU arch

Conceitos GNU Arch

Ramificação A ramificação é eficiente e pode abranger arquivos. Um branch simplesmente declara

facilitada a revisão ancestral, e o desenvolvimento continua a partir daí.

Mesclagem Devido ao registro permanente de todos os ancestrais e revisões mescladas, a

avançada mesclagem pode levar em consideração qual branch contém qual conjunto (patch) e
pode mesclar três vias com base em uma revisão ancestral compartilhada.

Assinaturas Cada conjunto de alterações é armazenado para evitar modificação acidental.

criptográficas

Renomeação Todos os arquivos e diretórios podem ser renomeados facilmente. Eles são rastreados
por um ID exclusivo. Desta forma, o histórico é preservado e os patches para os
arquivos são devidamente mesclados, mesmo se os nomes dos arquivos forem
diferentes entre os ramos.

[Link] 13/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Conceitos GNU Arch

Rastreamento de As permissões de todos os arquivos são rastreadas. Links simbólicos são suportados e
metadados rastreados da mesma forma que arquivos e diretórios.

Fonte: GNU arch ([s.d.], [s.p.]).

VIDEOAULA: LAUNCHPAD E GNU ARCH: HISTÓRICO, CICLO DE TRABALHO,

OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O vídeo tem o objetivo de chamar atenção sobre algumas funcionalidades relevantes do Launchpad e a
importância do software livre na construção de comunidades ativas, que disponibilizam entre seus usuários e
desenvolvedores o livre acesso ao código-fonte para que possam realizar alterações da maneira que desejarem,
possibilitando incremento da ferramenta.

Videoaula: Launchpad e GNU arch: histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

MONOTONE E DARCS: HISTÓRICO, CICLO DE TRABALHO, OPERAÇÕES,

CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O Monotone foi criado pelos desenvolvedores Nathaniel Smith e Graydon Hoare em 2005. Em seu status
técnico você observará que é escrito em C++. É possível importar projetos do sistema de controle de versão
CVS, além de ser um software de código aberto e ter uma boa documentação.

Entre suas principais operações estão o registro de revisões de arquivo, os grupos de conjuntos de revisão
(changesets) e a manutenção do histórico após mudanças de nome. O princípio do seu design é operar no
modelo distribuído do controle de versão, fazendo uso extensivo de criptografias para rastrear revisões de
arquivos (hash – algoritmo que mapeia dados) e para autenticar ações do usuário (por meio de assinaturas
criptográficas do sistema Rivest-Shamir-Adleman (RSA)) (MONOTONE, 2021).

No ciclo de trabalho, ele tem um suporte poderoso na rotina divergir e mesclar (diverge e merge),
possibilitando que incorpore a revisão inicial antes de integrar outra revisão. Embora suporte vários protocolos
de rede para sincronizar árvores, usa, de modo geral, seu protocolo específico chamado netsync, que é
bastante eficiente. É importante destacar que não existe um servidor específico, porque qualquer usuário
e cliente Monotone pode atuar como um servidor, de acordo com o princípio ponta a ponta (comunicação
direta entre as pontas) (MONOTONE, 2021).

Uma das primeiras ações de um novo usuário geralmente é sincronizar (clonar) um grande banco de dados
Monotone

existente, o que geralmente pode levar algumas horas devido às extensas verificações de validação e de
integração que realiza quando as revisões são movidas pela rede. Depois que o banco de dados inicial (clone) é
preenchido, as ações subsequentes geralmente são rápidas (MONOTONE, 2021).

Suas principais características são:

[Link] 14/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Uso de hash chamada Secure Hash Algorithm (SHA) para identificar arquivos ou grupo de arquivos
específicos.

Tem bom suporte de internacionalização e localização.

Tem design portátil, implementado em C++.

Importa projetos do sistema de controle de versões CVS.

Apresenta facilidade no aprendizado de uso (MONOTONE, 2021).

As principais desvantagens do Monotone são:

É menos popular que alguns sistemas, como Git e Mercurial.

Tem problemas na velocidade de certas operações, como a clonagem inicial.

Não tem interfaces gráficas amigáveis, embora o plugin TracMtn permita a navegação em um repositório e
seu histórico (MONOTONE, 2021).

Veja na Figura 7 um exemplo da interface das linhas de comandos.

Figura 7 | Interface de linhas de comandos do Monotone

Fonte: Monotone ([s.d.], [s.p.]).

O Darcs (Darcs Advanced Revision Control System) é um sistema de controle de versão distribuído criado por
David Roundy em 2002. Foi escrito inicialmente em C++ e, posteriormente, em Haskell em 2003. Foi elaborado
para substituir sistemas de CVS e SVN. Avaliando seu status técnico, entre os principais recursos estão: a
capacidade de escolher quais alterações aceitar de outros repositórios, a interação com outros repositórios
locais, repositórios remotos (HTTP, SSH) e e-mails e o fato de ser multiplataforma com licença General Public
License (GNU).

O sistema DARCS possui duas características distintas que o diferem de outros sistemas de controle de
revisão, sendo:

Cada árvore fonte é uma branch ou ramo, ou seja, diferente do Subversion, onde o código fonte é
armazenado em um repositório central, no Darcs cada cópia do código-fonte é um repositório completo.
Isso é bastante vantajoso, pois é possível acessar todas as funções da ferramenta a partir de qualquer
cópia do seu código, sem ter que fazer commit de mudanças incertas para um repositório central.

A manutenção do controle das mudanças, não de versões, ou seja, a árvore fonte não é o objeto
fundamental, e sim as correções (patches). Isso significa que um repositório pode ser visto como um
conjunto de patches que podem ser reordenados sem que a árvore seja modificada (MACHADO, 2019;
DARCS, 2021).

As operações fundamentais são: salvar e desfazer mudanças localmente, funcionar em qualquer servidor,
conceder permissão de decisões de escrita, mover arquivos e diretórios e e possibilitar configurações
padronizadas (MACHADO, 2019; DARCS, 2021).
[Link] 15/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Ele tem uma interface de linhas de comandos interativas, conforme a Figura 8.

Figura 8 | Interface de linhas de comando do Darcs

Fonte: DARCS ([s.d.], [s.p.]).

VIDEOAULA: MONOTONE E DARCS: HISTÓRICO, CICLO DE TRABALHO,

OPERAÇÕES, CARACTERÍSTICAS, INTERFACE E STATUS TÉCNICO
O vídeo apresenta uma comparação dos recursos do Darcs com relação ao SVN. Além disso exibe algumas
vantagens e desvantagens específicas do Darcs.

Videoaula: Monotone e Darcs: histórico, ciclo de trabalho, operações, características, interface e status técnico

Para visualizar o objeto, acesse seu material digital.

ESTUDO DE CASO
Você é gestor da área de tecnologia de uma empresa de grande porte chamada XYZ. A ferramenta de controle
de versão do software usado é a Mercurial, utilizada por grandes empresas como Facebook e Google. Ela é
bastante eficiente, o que significa que consegue desempenhar bem as funções básicas de um bom controle de
software, mas sua equipe, embora experiente profissionalmente, é nova na empresa e tem experiência com
outra ferramenta, o Subversion.

Diante disso, elabore estratégias propositivas para auxiliar sua equipe na apropriação e utilização da
ferramenta. Lembrando que uma estratégia propositiva é aquela em que se analisa os fatores envolvidos e os
resultados potenciais a partir do contexto real.

RESOLUÇÃO DO ESTUDO DE CASO

Ela é um pouco mais complexa de ser utilizada se comparada com a Subversion, mas é de aprendizagem fácil e
rápida pelas equipes de desenvolvedores e contém medidas de segurança para impedir erros. Além de ser
muito rápido e escalável, o Mercurial é mais simples que o Git, pois não existem tantas funções para aprender e
as funções são similares a outros sistemas.

É importante destacar que essa ferramenta vem equipada com uma interface web e tem uma excelente
documentação disponível na internet. Com essas informações, você pode incentivar seus funcionários a
conhecerem o Mercurial, indicando vários materiais de estudo para compreensão mais profunda dele.

Outro elemento importante a considerar é que a complexidade da ferramenta tem impacto direto na
produtividade dos desenvolvedores e é o fator decisivo para o aprendizado e a operação correta do recurso. Os
critérios usados para medir tal apropriação foi o número de comandos e de linhas dos textos de ajuda. O
detalhamento dos critérios são apresentados a seguir:

[Link] 16/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

A quantidade de comandos de uma ferramenta é um grande desafio no aprendizado dos usuários. Sendo
assim, quanto menor o número de comandos, mais fácil conhecê-los. Por outro lado, pouca quantidade de
comandos pode significar números de linhas de texto de ajuda complexos.

Os números de linhas dos textos de ajuda para os comandos têm o objetivo de apresentar o
funcionamento desses, sendo que devem apresentar formato de boa qualidade e conter o mínimo de
conteúdo necessário para descrever adequadamente os comandos.

Com base nisso, o Mercurial tem 55 comandos, sendo 18 desses considerados básicos (por exemplo, clone,
commit, diff, export, forget, init e log) e 37 avançados (por exemplo, comandos adicionais listados pelo comando
hg-help: add, remove, archive, backout, bisect, bookmarks, branch, etc.). Embora tais critérios não sejam
perfeitos e contenham problemas, são suficientes para apontar indícios a respeito da complexidade da
ferramenta, além de serem imparciais e de fácil medição. Essa informação é importante para monitorar o
aprendizado de sua equipe na apropriação e no uso do Mercurial. Certamente, esse acompanhamento no dia a
dia é essencial para a incorporação efetiva nas práticas de trabalho.

Você tomou ações propositivas para auxiliar sua equipe na apropriação e utilização do Mercurial, levando em
conta que seus colaboradores já conheciam um sistema de controle de versão e também a possibilidade de
aprendizado deles durante o dia a dia do trabalho.

Resolução do Estudo de Caso

Para visualizar o objeto, acesse seu material digital.

 Saiba mais
A principal referência da ferramenta Mercurial é seu manual oficial, o Mercurial: The Definitive Guide,
escrito por Bryan O'Sullivan. Pode ser baixado gratuitamente.

O site oficial do Mercurial disponibiliza um Wiki com informações e 37 links para download de instaladores
para vários outros sistemas operacionais como Mac OS X, Solaris, AIX e FreeBSD. No mesmo site estão
disponíveis tutoriais para iniciantes e documentos que mostram de maneira ilustrada como o Mercurial
funciona.

O site oficial do Darcs tem comunidade e tutoriais para utilização dele.

Aula 3

ANÁLISE DAS PRINCIPAIS CARACTERÍSTICAS DOS

REPOSITÓRIOS
Comparativo das características dos repositórios centralizados; Comparativo das características
dos repositórios distribuídos; Comparativo geral dos repositórios e visão da experiência do
usuário sobre os repositórios.

19 minutos

INTRODUÇÃO

[Link] 17/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Nesta aula você terá uma visão geral comparativa das características dos repositórios centralizados (RCS, CVS,
SVN e Microsoft Visual SourceSafe) e distribuídos (BAZZAR, Mercurial, GNU arch, Monotone, DARCS e
Launchpad).

Apresentaremos também um comparativo geral desses repositórios e os elementos que podem caracterizar a
experiência do usuário.

Convido você a ler e estudar este material que foi elaborado de forma cuidadosa para ajudá-lo em seu percurso
de estudos.

Bons estudos!

COMPARATIVO DAS CARACTERÍSTICAS DOS REPOSITÓRIOS CENTRALIZADOS

Apresentaremos um comparativo de algumas características dos repositórios centralizados. Primeiramente, o
Concurrent Version System (CVS) possibilita o armazenamento de todas as informações controlados pelo
sistema de controle de versões em arquivos dispostos e contidos em uma hierarquia de diretórios do
repositório.

Já o Revision Control System (RCS), que opera por meio de um conjunto de comandos Unix, isto é, uma lista de
comandos do sistema operacional Linux, gerencia um grupo de revisões. O Subversion consegue controlar as
alterações realizadas na cópia de trabalho que ainda não foram enviadas ao repositório. Isso é feito por meio de
um conjunto de mensagens, chamadas de logs, que ficam gravadas no repositório após um usuário descrever
as alterações feitas relacionadas a um commit. Já o SourceSafe atua como um sistema de controle de versões
que centraliza os arquivos, o gerenciamento de acesso e o histórico das modificações.

Veja a seguir o quadro comparado do CVS, Subversion, RCS e Visual SourceSafe (Quadro 1) em relação à:

Licença adotada.

Portabilidade (compatibilidade com os principais sistemas operacionais).

Interoperabilidade (capacidade de um sistema se comunicar de forma transparente com outros sistemas, o

ambiente de desenvolvimento integrado - IDE).

Documentação disponível, facilidade da implantação da ferramenta.

Implantação de rede.

Integração de rede.

Replicação remota de repositório.

Quadro 1 | Comparativo entre RCS, CVS, SVN e Visual SourceSafe (Parte A)

Itens RCS CVS SVN Visual Source Safe

Licença GNU GPL GNU GPL v.2 Apache/BSD Microsoft

Portabilidade Regular Regular Excelente Ruim

Interoperabilidade Regular Regular Excelente Regular

[Link] 18/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Itens RCS CVS SVN Visual Source Safe

Documentação Regular Boa Excelente Boa

Implantação Regular Boa Regular Regular

Integração de rede Regular Regular Excelente Regular

Replicação remota de repositório Indiretamente Indiretamente Indiretamente Indiretamente

Fonte: adaptado de Freitas (2010).

Você observará, a seguir, o Quadro 2 comparando o CVS, o Subversion, o RCS e o Visual SourceSafe referente:

À atomicidade da operação de commit.

À propagação de alterações para outros repositórios.

Ao gerenciamento de permissões.

Às informações, linha por linha, de alterações em um arquivo.

Ao histórico de versões.

Ao suporte a changesets.

Ao suporte a movimentações e renomeações de arquivos e diretórios.

Quadro 2 | Comparativo entre RCS, CVS, SVN e Visual SourceSafe (Parte B)

Visual Source
Itens RCS CVS SVN Safe

Propagação de alterações de Indiretamente Indiretamente Indiretamente Indiretamente

repositórios

Commits atômicos Não Não Não Não

Permissões de acesso ao Repositório, Repositório, Repositório, Repositório,

repositório Diretório, Diretório, Diretório, Diretório,

Arquivos Arquivos Arquivos Arquivos

Histórico de versões Regular Regular Excelente Bom

Histórico com informações Não Sim Sim Não

linha a linha

Suporte a Changeset Não Não Parcial Parcial

[Link] 19/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Visual Source
Itens RCS CVS SVN Safe

Renomear/movimentar Não Não Sim Não

arquivos ou diretórios

Fonte: adaptado de Freitas (2010).

O Quadro 3 a seguir compara o CVS, o Subversion, o RCS e o Visual SourceSafe quanto:

Ao suporte a cópias de arquivos e diretórios.

Ao suporte à mesclagem (merge) inteligente após renomeações.

Ao monitoramento de alterações locais.

Ao suporte à atribuição de mensagens de log a cada arquivo em um commit.

Ao suporte a checkout parcial.

À disponibilidade de ferramentas de interface web.

À disponibilidade de clientes de interface gráfica para a ferramenta.

Quadro 3 | Comparativo entre RCS, CVS, SVN e Visual SourceSafe (Parte C)

Visual Source
Itens RCS CVS SVN Safe

Cópias de arquivos ou diretórios Sim Sim Sim Sim

Merge inteligente após renomear/movimentar Não Não Não Não

arquivos

Mensagens de log para cada arquivo do commit Não Não Não Não

Monitoramento de alterações não enviadas ao repositório Não Não Sim Não

Trabalha com apenas um diretório do repositório (checkout Não Não Não Não
parcial)

Interface web Não Sim Sim Sim

Interface gráfica de usuário Não Sim Sim Sim

Fonte: adaptado de Freitas (2010).

[Link] 20/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

VIDEOAULA: COMPARATIVO DAS CARACTERÍSTICAS DOS REPOSITÓRIOS

CENTRALIZADOS
O vídeo mostra a importância dos sistemas de controle de versões, a relevância do método de sincronização
que ocorre neles e como ocorre a tal sincronização nos sistemas centralizados.

Videoaula: Comparativo das características dos repositórios centralizados

Para visualizar o objeto, acesse seu material digital.

COMPARATIVO DAS CARACTERÍSTICAS DOS REPOSITÓRIOS DISTRIBUÍDOS

Você compreenderá algumas características dos repositórios distribuídos a partir de comparativos de suas
características disponibilizados por meio de quadros.

Veja a seguir uma comparação do BAZAAR, Mercurial, Monotone, Darcs, GNU arch e Launchpad (Quadro 4) em
relação à:

Licença adotada.

Portabilidade (compatibilidade com os principais sistemas operacionais).

Interoperabilidade (capacidade de um sistema se comunicar de forma transparente com outros sistemas, o

ambiente de desenvolvimento integrado - IDE).

Documentação disponível, facilidade da implantação da ferramenta.

Implantação de rede.

Integração de rede.

Replicação remota de repositório.

Quadro 4 | Comparativo entre BAZAAR, Mercurial, Monotone, Darcs, GNU arch e Launchpad (Parte A)

Itens Arch BAZAAR Monotone Mercurial Launchpad Darcs

Licença GNU GNU GNU GPL GNU GPL GNU Affero General GNU
GPL GPL v2 Public License GPL

Portabilidade Boa Boa Boa Boa Boa Boa

Interoperabilidade Boa Boa Boa Excelente Boa Boa

Documentação Regular Boa Boa Boa Boa Boa

Implantação Regular Boa Boa Excelente Boa Boa

Integração de rede Regular Boa Boa Excelente Boa Boa

[Link] 21/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Itens Arch BAZAAR Monotone Mercurial Launchpad Darcs

Replicação remota de Sim Sim Sim Sim Sim Sim

repositório

Fonte: adaptado de Freitas (2010).

A seguir, observe o quadro comparativo do BAZAAR, Mercurial, Monotone, Darcs, GNU Arch e Launchpad
referente:

À atomicidade da operação de commit.

À propagação de alterações para outros repositórios.

Ao gerenciamento de permissões.

Às informações, linha por linha, de alterações em um arquivo.

Ao histórico de versões.

Ao suporte a changesets.

Ao suporte a movimentações e renomeações de arquivos e diretórios (FREITAS, 2010).

Quadro 5 | Comparativo entre BAZAAR, Mercurial, Monotone, Darcs, GNU arch e Launchpad (Parte B)

Itens Arch BAZAAR Monotone Mercurial Launchpad Darcs

Propagação de Sim Sim Sim Sim Sim Sim

alterações de
repositórios

Commits atômicos Sim Sim Sim Sim Sim Sim

Permissões de acesso Repositório, Repositório, Repositório, Repositório, Repositório, Repositó

ao repositório Diretório, Diretório, Diretório, Diretório, Diretório, Diretór
Arquivos Arquivos Arquivos Arquivos Arquivos Arquivo

Histórico de versões Sim Sim Sim Sim Sim Sim

Histórico com Sim Sim Sim Sim Sim Sim

informações linha a
linha

Suporte a changeset Não Não Não Sim Sim Sim

Renomear/movimentar Sim Sim Sim Sim Sim Sim

arquivos ou diretórios

[Link] 22/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Fonte: adaptado de Freitas (2010).

Acompanhe as comparações entre BAZAAR, Mercurial, Monotone, Darcs, GNU arch e Launchpad no Quadro 6,
quanto:

Ao suporte a cópias de arquivos e diretórios.

Ao suporte à mesclagem (merge) inteligente após renomeações.

Ao monitoramento de alterações locais.

Ao suporte à atribuição de mensagens de log a cada arquivo em um commit.

Ao suporte a checkout parcial.

À disponibilidade de ferramentas de interface web.

À disponibilidade de clientes de interface gráfica para a ferramenta (FREITAS, 2010).

Quadro 6 | Comparativo entre BAZAAR, Mercurial, Monotone, Darcs, GNU arch e Launchpad (Parte C)

Itens Arch BAZAAR Monotone Mercurial Launchpad Darcs

Cópias de arquivos ou Não Não Não Sim Não Não

diretórios

Merge inteligente após Sim Sim Sim Sim Sim Sim

renomear/movimentar

arquivos

Mensagens de log para cada Não Sim, com Não Não Não Não
arquivo do commit plugin

Monitoramento de alterações Sim Sim Sim Sim Sim Sim

não enviadas ao repositório

Trabalha com apenas um Não Não Não Não Não Não

diretório do repositório
(checkout parcial)

Interface web Sim, Sim, Sim Sim Sim, com Sim

com com plugin plugin
plugin

Interface gráfica de usuário Sim Sim Sim Sim, com Sim Sim
plugin

Fonte: adaptado de Freitas (2010).

[Link] 23/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

VIDEOAULA: COMPARATIVO DAS CARACTERÍSTICAS DOS REPOSITÓRIOS

DISTRIBUÍDOS
O vídeo tem o objetivo de chamar atenção sobre alguns dos benefícios dos sistemas de controle de versão
distribuídos, como a rapidez nos processos, a autonomia dos desenvolvedores e, do ponto de vista dos
gestores, a confiabilidade e a redução de custo. Aborda também suas principais desvantagens: a complexidade
no entendimento de seus processos e o fato de grandes equipes poderem causar limitações no uso de uma
ferramenta.

Videoaula: Comparativo das características dos repositórios distribuídos

Para visualizar o objeto, acesse seu material digital.

COMPARATIVO GERAL DOS REPOSITÓRIOS E VISÃO DA EXPERIÊNCIA DO

USUÁRIO SOBRE OS REPOSITÓRIOS
Como estudado anteriormente, os sistemas de controle de versão centralizados e distribuídos apresentam
características diferentes. Por exemplo, os repositórios com base nos sistemas centralizados possuem um
servidor central e diversas estações de trabalho. Já nos repositórios baseados em sistemas distribuídos, cada
usuário tem seu próprio “servidor” que pode comunicar-se com outros e entre si. As mais importantes
atribuições dos principais sistemas de controle de versão abordados, de forma sintética, são:

centralizados: basicamente estão ligados a um servidor central e a diversas estações ou espaços de

trabalho, baseados em uma topologia usário-servidor; os representantes que estudamos foram: RCS, CVS,
SVN e Microsoft Visual SourceSafe.

distribuídos: essencialmente cada área de trabalho tem seu próprio “servidor”, que podem comunicar-se
entre si; as principais ferrramentas abordadas foram: BAZAAR, Mercurial, Monotone, Darcs, GNU arch e
Launchpad.

Com base nesses sistemas de controle de versão, é possível aprender sobre a experiência dos usuários. Mas o
que é isso? A experiência do usuário é descrita pela forma como as pessoas experimentam e usam um
aplicativo móvel, um produto ou um software ou interagem com serviços. Existem algumas formas de se avaliar
tal experiência, como pelo design visual, pela usabilidade e aprendizado, acessibilidade, atratividade,
credibilidade, intuitividade e desempenho técnico. Nesse caso, você conhecerá a experiência de um usuário de
sistemas de controle de verso concernentes à complexidade de aprendizado e usabilidade por meio das linhas
de comando.

Por exemplo, o Subversion tem menor complexidade no aprendizado, pois com um conhecimento básico de
conceitos associados ao controle de versão de software, é possível executar os comandos dele. Além disso, é
apropriado para equipes menores que não tenham uma distribuição geográfica complexa, pois, por ser
centralizado, depende de uma boa disponibilidade de redes, e neste caso o servidor necessita de muita
capacidade de processamento. Ele foi escrito para ser um substituto para o CVS, ou seja, com recursos
similares, mas sem os problemas e as omissões de recursos que muito frequentemente incomodam aos
usuários do mesmo. Um dos objetivos do Subversion foi para que pessoas acostumadas ao CVS achassem a
mudança para ele relativamente suave.

[Link] 24/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Já o Mercurial, embora seja uma ferramenta mais complexa, apresenta uma aprendizagem fácil e rápida por
grandes equipes de desenvolvedores e contém medidas de segurança para impedir erros. Além disso, opera
bem com projetos que utilizam o Windows, por ser a ferramenta que possui a implantação mais simples nesse
sistema operacional.

O CVS é um sistema que possibilita fácil aprendizagem, pois é muito simples na atualização dos arquivos e
revisões. Embora seja considerado uma tecnologia antiga, o CVS é bastante útil para qualquer desenvolvedor
fazer o backup de arquivos e de compartilhamento.

O GNU arch tem uma grande quantidade de comandos, o que pode dificultar a aprendizagem e a usuabilidade
dos usuários. O BAZAAR é razoavelmente fácil de aprender para aqueles que estão familiarizados com as
interfaces de linha de comando dos sistemas de controle de versões tradicionais, como o CVS e o SVN. As
ferramentas Mercurial e Monotone contêm uma boa quantidade de conjunto de comandos, mas que seguem as
convenções dos sistemas mais conhecidos.

VIDEOAULA: COMPARATIVO GERAL DOS REPOSITÓRIOS E VISÃO DA

EXPERIÊNCIA DO USUÁRIO SOBRE OS REPOSITÓRIOS
O vídeo apresenta uma comparação de alguns elementos nos sistemas de controle de versão centralizados e
distribuídos, como a autonomia do trabalho dos desenvolvedores, a rapidez nas operações, o tamanho do
repositório, a facilidade de trabalho e o acesso à internet.

Videoaula: Comparativo geral dos repositórios e visão da experiência do usuário sobre os repositórios

Para visualizar o objeto, acesse seu material digital.

ESTUDO DE CASO
Imagine que você é gestor da área de desenvolvimento de softwares de uma grande empresa chamada ABC. Ela
quer mudar sua ferramenta de sistemas de controle de versão atual, que é baseada em modelo distribuído,
pois considera que não está atendendo às necessidades. A maioria dos colaboradores da equipe tem
experiência entre um e cinco anos de trabalho. Você e sua equipe analisaram as ferramentas considerando
itens como:

Popularidade.

Desempenho (demora nas operações).

Eficácia (registro do processo de trabalho, possibilidade do trabalho em equipe e criação e manutenção do

projeto).

Adequação (tamanho e experiência da equipe).

Simplicidade (facilidade de aprender e uso que leva a menos erros de operações).

Após pesquisas e intensos debates entre a equipe de desenvovimento, vocês chegaram a três SVCs: Git,
Mercurial e Subversion. Contudo, o Git foi um dos escolhidos devido à sua populariade, não necessariamente
por ser a melhor opção para a empresa e para a equipe.

[Link] 25/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Diante disso, você precisa convencer sua equipe que uma das melhores opções são uma das outras duas
ferramentas, o Mercurial ou o Subversion, especialmente o promeiro, pode ter um modelo distribuído, sistema
já conhecido por sua equipe.

RESOLUÇÃO DO ESTUDO DE CASO

Primeiro, você precisa tentar fazer sua equipe entender que, embora o Git seja bastante popular, tenha bom
desempenho e seja eficaz, pode não ser a ferramenta mais adequada. No caso dele, sua popularidade se deve
ao GitHub, que é uma plataforma de hospedagem de código para controle de versão e colaboração, que aderiu
aos projetos projetos open source. Além disso, ao invés de ter páginas estáticas, inovou ao criar uma aplicação
web dinâmica, com uma interface agradável e que conseguiu tornar a contribuição de software por meio de pull
requests um processo fácil e sociável.

O Subversion é uma ferramenta eficaz, bastante popular e tem bom desempenho. Além disso, é simples e
adequada para sua equipe, pois o tempo de aprendizado é curto e a chance de desastres causados por
imperícia é menor. Por exemplo, para usar o Subversion, você precisa entender os conceitos básicos de controle
de versão: arquivo, diretório de trabalho, revisão, changeset, ramos e etiquetas (tags). Também é necessário
conhecer as particularidades de implementação da ferramenta em relação à ramificação por meio de diretórios
e às convenções da estrutura de diretórios.

O Mercurial é pouco mais complexo que o Subversion porque, além dos conceitos de controle de versão
centralizado, é necessário compreender também os conceitos básicos do controle de versão distribuído, como a
sincronização de repositórios e a formulação matemática dos registros do históricos. Entretanto, os comandos
do Mercurial são similares aos do Subversion, pois foi projetado para oferecer um conjunto de comandos
pequenos, seguro e fácil de usar que é suficientemente poderoso para a maioria dos usuários.

As operações avançadas estão disponíveis por meio de extensões que permitem a integração desses recursos
diretamente no núcleo da ferramente. Assim, o conjunto de operações e funcionalidades do Mercurial pode ser
incrementado à medida que aumenta o nível de conhecimento e de necessidade do usuário.

O Mercurial ainda tem medidas internas de segurança que evitam estragos por imperícia mesmo em operações
avançadas de manipulação de histórico. O conceito de phases (fases), por exemplo, é transparente ao usuário e
evita que um histórico já compartilhado seja reescrito por acidente.

Dessa forma, é possível chegar à conclusão que dentro dos parâmentros estabelecidos, a ferramenta mais
adequada é o Mercurial, pois é um SCV distribuído, com conceitos com os quais sua equipe já está familiarizada,
sendo mais fácil de aprender. Além disso, é eficaz, simples e tem bom desempenho.

Resolução do Estudo de Caso

Para visualizar o objeto, acesse seu material digital.

 Saiba mais
No site Cadernos CiComp você poderá encontrar alguns tutoriais sobre como funcionam os sistemas de
controle de versão e tutoriais sobre lógica e linguagem de programação Python.

Aula 4

GERENCIAMENTO DOS CONTROLES DE VERSÕES

[Link] 26/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Configurações de softwares; Históricos dos sistemas de controle de versões e principais

conceitos; Funcionamento do modelo distribuído e centralizado.

18 minutos

INTRODUÇÃO
Nesta aula você aprenderá a importância do gerenciamento de configuração de softwares, podendo ter uma
visão geral das práticas baseadas em tal gerenciamento no desenvolvimento de projetos de softwares.

Além disso, apresentaremos um histórico de elaboração dos sistemas de controle de gestão que ajuda a
entender por que usamos tais ferramentas e quais seus recursos e principais conceitos. Também serão
abordados fundamentos dos sistemas centralizados e distribuídos.

Leia e estude este material que foi elaborado de forma cuidadosa para ajudá-lo em seu percurso de estudos. É
sempre bom lembrar que o conhecimento pode levá-lo a construir de forma mais adequada seus objetivos na
vida pessoal e profissional.

Bons estudos!

CONFIGURAÇÕES DE SOFTWARES
O gerenciamento de configuração dos softwares surgiu nos anos 60, restrito nas esferas militares, sendo
aplicado nas instituições civis somente nos anos 80. Essa gestão tem a função de coordenar o desenvolvimento
de software, identificando, organizando e controlando moficações e aplicando padrões e procedimentos
(SOMMERVILLE, 2003).

A gestão da configuração é observada a partir de seis perspectivas dentro de uma empresa, que são:

Da pessoa, referente aos aspectos organizacionais relativos a projetos que são criados pelas pessoas.

Do produto, relacionada à natureza dele e suas características (se é simples ou complexo ou se tem
impacto direto na vida das pessoas).

Do projeto, associada ao desempenho do seu desenvolvimento e durante todo o ciclo de vida.

Do interorganizacional, referente aos setores interrelacionados da empresa, como infraestrutura, bens e

documentação.

Da compreensão dos processos da empresa para que possam ser aprimorados.

Da disponibilidade das ferramentas no mercado que possibilitam o desenvolvimento, a implementação e

o monitoramento de softwares e de repositórios (FREITAS, 2010).

Além disso, a gestão de configuração de software pode ser visualizada a partir das perpectivas dos processos
gerenciais e dos procedimentos de desenvolvimento dos softwares.

Figura 1 | Perspectivas de gestão de configuração de softwares

[Link] 27/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Fonte: adaptado de Murta (2006) e Freitas (2010).

Do ponto de vista gerencial, é possível encontrar cinco subdivisões que orientam as funções de gestão de
organização dos softwares e dados. A primeira delas é a identificação, que define, nomeia numera e descreve
as características ou as configurações de softwares. A segunda é o controle dessas configurações, que
monitora a evolução dos itens de identificação. A terceira subdivisão refere-se à função de contabilização, que
armazena e permite o acesso a todas as informações geradas pelas outras funções. A quarta tem a função de
avaliar e revisar a configuração, compreendendo a auditoria funcional. E, por fim, temos a função de
gerenciamento de liberação e entrega, responsável pela construção e liberação dos itens de configuração,
além da entrega dos produtos de software (MURTA, 2006; FREITAS, 2010).

Do ponto de vista do desenvolvimento, há três diferentes sistemas, sendo:

Sistema de controle de versões: possibilita a identificação dos itens de configuração e a evolução dos
mesmos, de forma distribuída, concorrente e disciplinada. Por meio deste sistema é possível monitorar as
diversas solicitações de modificação, que são tratadas em paralelo, não corrompendo o sistema como um
todo.

Sistema de controle de modificações: responsável pelo controle da configuração, armazenando as

informações das solicitações de modificação e comunicando-as aos outros participantes.

Sistema de gerenciamento de construção: automatiza o processo de transformação dos artefatos de

software em um arquivo executável e estrutura as linhas bases selecionadas para a liberação (MURTA,
2006; FREITAS, 2010).

VIDEOAULA: CONFIGURAÇÕES DE SOFTWARES

O vídeo mostra o conceito básico de gerenciamento de configuração do software e as principais funções e
ferramentas de apoio que são: o controle da mudança, o controle de versão e a integração contínua.

Videoaula: Configurações de softwares

Para visualizar o objeto, acesse seu material digital.

HISTÓRICOS DOS SISTEMAS DE CONTROLE DE VERSÕES E PRINCIPAIS

CONCEITOS

[Link] 28/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

O primeiro sistema de controle de versões (VCS) foi desenvolvido em 1972, no laboratório Bell Labs, por Marc J.
Rochkind e se chamava Source Code Control System (SCCS). Em seguida, surgiu o Revision Control System (RCS),
em 1982, e uma de suas principais contribuições foi uma técnica de armazenamento deltas, o que muitos
desenvolvedores de VCSs consideravam chave para o surgimento de técnicas de junção. Já o CVS (Concurrent
Versions System) foi elaborado em 1986, com base no RCS, mas com a possibilidade de gerenciar projetos
inteiros e não só um arquivo individualmente, como no RCS.

O Subversion foi desenvolvido com o objetivo de melhorar as funcionalidades do CVS. Entre os sistemas de
controle de versão que trabalham de forma distribuída que mais ganharam adeptos e maior aceitação estão o
Mercurial, criado por Matt Mackall, e o Git, desenvolvido por Linus Torvalds, também criador do sistema
operacional Linux (FREITAS, 2010).

Observe na Figura 2 os principais sistemas de controle de versão divididos em livres, que categorizam softwares
gratuitos e/ou de código aberto, e em comerciais, aqueles que são proprietários e pagos.

Figura 2 | Sistemas de Controle de Versões

Fonte: Freitas (2010, p. 7).

É importante ter em mente os conceitos comuns relacionados às principais ferramentas de controle de versões,
que são:

Item de configuração: representa cada um dos elementos de informação que é criado ou que é
necessário durante o desenvolvimento de um produto de software. São identificados de maneira única e
sua evolução deve ser passível de rastreamento.

Repositório: o local de armazenamento de todas as versões dos arquivos.

Versão: representa o estado de um item de configuração que está sendo modificado.

Revisão: uma versão que resulta de correção de defeitos ou de implementação de uma nova
funcionalidade. As revisões evoluem sequencialmente.

[Link] 29/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Ramo: uma versão paralela ou alternativa. Os ramos não substituem as versões anteriores e são usados
concorrentemente em configurações alternativas.

Espaço de trabalho: o espaço temporário para manter uma cópia local da versão a ser modificada
(FREITAS, 2010, p. 7 e 8).

Além desses conceitos, existem nomes de comandos básicos na maioria dos sistemas de controle de versões,
por exemplo:

checkout (clone): cria uma cópia de trabalho local do repositório.

update: envia as modificações contidas no repositório para a área de trabalho.

Commit: cria o artefato no repositório pela primeira vez ou cria uma nova versão do artefato quando este
passa por uma modificação.

merge: mescla versões diferentes com o objetivo de gerar uma única versão que agregue todas as
alterações realizadas. Para a realização da mesclagem são utilizados algoritmos que diferenciam os itens
de configuração em questão, o que caracteriza o conceito de delta.

changeset: é uma coleção atômica de alterações realizadas nos arquivos do repositório (FREITAS, 2010, p.
8).

VIDEOAULA: HISTÓRICOS DOS SISTEMAS DE CONTROLE DE VERSÕES E

PRINCIPAIS CONCEITOS
O vídeo tem o objetivo de chamar atenção sobre a relevância do gerenciamento de configuração como um
requisito de implementação já no nível inicial de diversos modelos no processo de desenvolvimento de
softwares, provendo qualidade para os mesmos. Além disso, demosntra como esta área está interelacionada
com gerência de projetos e teste e qualidade de softwares.

Videoaula: Históricos dos Sistemas de Controle de Versões e principais conceitos

Para visualizar o objeto, acesse seu material digital.

FUNCIONAMENTO DO MODELO DISTRIBUÍDO E CENTRALIZADO

Os repositórios centralizados têm um servidor central e diversas estações ou espaços de trabalho baseados em
uma opologia usuário-servidor, isto é, existe um repositório central e diversas cópias de trabalho. Neste
modelo, as estações de trabalho passam pelo servidor para poderem se comunicar. Mas como é
possível realizar o trabalho com um modelo de repositório centralizado?

Imagine que você e outra desenvolvedora iniciem seus trabalhos em um VCS centralizado. De início, é preciso
fazer o checkout no repositório atual para levar para suas estações de trabalho uma parte dele. Então,
comecem seus projetos no mesmo estágio. Contudo, a desenvolvedora X foi mais rápida e já finalizou
as revisões, fazendo um commit para o repositório. Quando você for fazer commit, será avisado que ela
modificou o repositório. Neste caso, faça um update na sua área de trabalho e, não havendo problemas, o VCS
mesclará ou juntará suas mudanças com as da outra desenvolvedora, ou seja ocorrerá o merge. Então, você
poderá fazer um commit (Figura 3).

[Link] 30/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Figura 3 | Funcionamento do sistema de controle de versão centralizado

Fonte: adaptada de Cunha Neto (2017).

O que aconteceria se vocês trabalhassem em um VCS distribuído? As rotinas de trabalho de um usuário de um

sistema de controle de versão distribuído é similar ao modelo centralizado, mas há algumas diferenças: as
áreas de trabalho dos desenvolvedores funcionam como uma espécie de “servidor” que podem se
comunicar entre si. É recomendado que se tenha um servidor central remoto, evitando ramificações
desnecessárias do projeto e o desaparecimento ou a perda de controle de todo o processo. Muitos projetos
adotam a topologia usuário-servidor ao empregar ferramentas de controle de versões descentralizadas,
facilitando o trabalho dos desenvolvedores.

No caso de você e a desenvolvedora X elaborarem um projeto em um VCS distribuído, deveriam fazer um clone
ou uma cópia do conteúdo dos respectivos repositórios, fazendo publicações (operação chamada de commit)
neles. Por exemplo, enquanto a desenvolvedora X estiver trabalhando na área de trabalho dela, você poderia
trazer as alterações dela para sua área de trabalho (operação chamada de pull). Em seguida, você deveria
mesclar (fazer um merge) sua área de trabalho com as alterações feitas por ela e publicá-las (fazer um commit).
Enquanto isso, a outra desenvolvedora continuaria elaborando o projeto e faria um novo commit. Você enviaria
sua revisões ao repositório dela por meio da operação designada push, e ela as combinaria com o histórico de
revisões já existentes (Figura 4).

Figura 4 | Funcionamento do sistema de controle de versão distribuído

Fonte: adaptada de Cunha Neto (2017).

[Link] 31/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

É importante ter em mente esses princípios básicos de funcionamento dos sistemas de controle de versão (VCS)
centralizados e distribuídos.

VIDEOAULA: FUNCIONAMENTO DO MODELO DISTRIBUÍDO E CENTRALIZADO

O vídeo apresenta os tipos de ramos ou branches de um sistema de controle de versão, que podem ser:
principal, dedicado, de manutenção e individual. Existem também três tipos, conforme sua duração: curto,
médio e longo.

Videoaula: Funcionamento do modelo distribuído e centralizado

Para visualizar o objeto, acesse seu material digital.

ESTUDO DE CASO
Neste estudo de caso, você deve analisar o uso de um sistema de controle de versão com base no conceito de
experiência do usuário para adoção de uma ferramenta. A experiência do usuário (ou user experience) descreve
o que e como as pessoas usam uma ferramenta digital ou outros serviços, seja um site, um aplicativo móvel, um
serviço ou um programa. Existem vários elementos que contribuem para a concepção de boas experiências
para o público, como a usabilidade, o valor, a adotabilidade, a desejabilidade e a simplicidade. Primeiro, é
necessário entender o significado dos elementos da experiência de usuário, que são:

Usabilidade: envolve a ideia de como os usuários precisam completar ações dentro de uma sistema
qualidade.

Adotabilidade: a facilidade de adoção do software pelos usuários.

Desejabilidade: a experiência de uso desejável, agradável, intuitiva e até mesmo divertida.

Valor: é fundamental que o produto entregue aos usuários algo que eles realmente queiram ou precisem.

Simplicidade: se as operações da ferramenta são simples de usar.

RESOLUÇÃO DO ESTUDO DE CASO

A partir do conhecimento dos elementos, como a usabilidade, o valor, a desejabilidade, a simplicidade e a
adotabilidade, é

possível chegar a algumas considerações.

Comparando o Subversion e o Mercurial, note que os dois cumprem o pré-requisito de usabilidade, isto é, a
ideia de como os usuários precisam completar ações dentro de um sistema qualidade, neste caso, um VCS. Isso
acontece porque eles contêm ferramentas das principais operações dos sistemas de controle de versão, como
histórico das ações com informações linha a linha, a possibilidade de renomear/movimentar e o
monitoramento de alterações não enviadas ao repositório e permissões de acesso ao repositório.

Com relação à adotabilidade, é preciso levar em consideração o quão fácil é para que os usuários comecem a
usar a ferramenta. É necessário pensar na aquisição ou no download até a conclusão da ação inicial.
Neste aspecto, é relevante entender detalhamente a demanda, o problema de uma empresa e as características

[Link] 32/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

da equipe envolvida no uso da ferramenta. Por exemplo, se o VCS será aplicado em uma empresa grande ou
pequena, se a equipe é experiente ou inexperiente e quais são as condições de infraestrutura.

Quanto ao valor que os usuários de um VCS atribuem ao uso dele, é importante saber se o sistema de controle
de versão realmente cumpre sua finalidade, que é gerenciar as diferentes versões de um documento,
oferecendo aos usuários uma maneira muito mais inteligente e eficaz de organizar um projeto. Com o VCS é
possível acompanhar um histórico de desenvolvimento, desenvolver paralelamente e ainda apresentar
oferecer outras vantagens, como customizar uma versão, incluir outros requisitos, finalidades
específicas, layout e outros, sem mexer no projeto principal, ou resgatar o sistema em um

ponto que estava estável. Tudo isso pode ser feito sem mexer na versão principal.

Concernente à desejabilidade, é possível entender que a experiência de uso tem que ser desejável, agradável e
intuitiva. Neste elemento, deve-se inferir que a compreensão dos principais conceitos dos sistemas de controle
de versão (ramos, históricos, versões, revisões, etc.), dos principais comandos (checkout, commit, merge, etc.) e
do funcionamento dos modelos centralizados e distribuídos podem auxiliar a ter uma experiência mais
agradável e desejável. É importante também levar em consideração que algumas ferramentas são mais
intuitivas.

Relacionado à simplicidade de um SVN, isto é, se as operações da ferramenta são de simples uso, é possível
fazer algumas considerações. Por exemplo, o SVN é um sistema de controle de versão centralizado que quem já
conhece seu sistema de trabalho poderá considerar mais simples de se adaptar a outras ferramentas. Já ,o caso
do Git pode ser mais difícil, pois sua estrutura é mais complexa, com muitas topologias para configurar
repositórios em diferentes situações e não há nenhum padrão. Os repositórios SVN podem ser mais
gerenciáveis e mais simples do ponto de vista de um gestor ou administrador.

Desta forma, é possível fazer uma análise crítica da experiência dos desenvolvedores no uso de um sistema de
controle de versão.

Resolução do Estudo de Caso

Para visualizar o objeto, acesse seu material digital.

 Saiba mais
O material Gerenciamento de Configuração de Software, produzido pelo professor Vitor Hugo Santiado da
USP, traz conceitos visualizados graficamente sobre a metodologia de gestão e o exemplo de um
gerenciador de projetos conhecido como Redmine. Além disso, aborda conceitos do sistema de controle de
versão Git.

REFERÊNCIAS
3 minutos

Aula 1
FREITAS, D. T. M. Análise Comparativa entre Sistemas de Controle de Versões. Dissertação (Mestrado em
Computação).

Instituto de Ciências Exatas, Universidade Federal de Juiz de Fora. Juiz de Fora, 2010.
[Link] 33/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

PAIVA, D. M. B.; JUNQUEIRA, D. C.; FORTES, R. P. M. Introdução ao uso de CVS (Concurrent Version System).
Relatório técnico nº 172. Instituto de Ciências Matemáticas e de Computação - ICMC: São Carlos, 2002. (Notas
didáticas do ICMC). Disponível em: [Link] Acesso em: 12

ago. 2021.

TICHY, W. F. RCS: A System for Version Control (1984). Department of Computer Science Technical Reports.
Paper 394. Disponível em: [Link] Acesso em: 12 ago. 2021.

Aula 2
BAZAAR EXPLORER. Advanced Version Control Made Simple. [s.d.]. Disponível em: [Link] Acesso
em: 7 dez. 2021.

DARCS. Disponível em: [Link] Acesso em: 24 set. 2021.

FREITAS, D. T. M. Análise Comparativa entre Sistemas de Controle de Versões. Dissertação (Mestrado em

Computação).

Instituto de Ciências Exatas, Universidade Federal de Juiz de Fora. Juiz de Fora, 2010.

GNU ARCH. Disponível em: [Link] Acesso em: 7 dez. 2021.

MACHADO, J. N. A eficácia do controle de versão de software: o sistema distribuído. Revista Científica Semana
Acadêmica.

Fortaleza, ano MMXIX, n. 159, 20 mar. 2019. Disponível em: [Link] Acesso em: 24 set. 2021.

MONOTONE. Disponível em: [Link] Acesso em: 14 set. 2021.

Aula 3
FREITAS, D. T. M. Análise Comparativa entre Sistemas de Controle de Versões. Dissertação (Mestrado em
Computação). Instituto de Ciências Exatas, Universidade Federal de Juiz de Fora. Juiz de Fora, 2010.

MACHADO, J. N. A eficácia do controle de versão de software: o sistema distribuído. Revista Científica Semana
Acadêmica. Fortaleza, ano MMXIX, n. 159, 20 mar. 2019. Disponível em: [Link] Acesso em: 24 set.
2021.

SCHMARZO, B. Big Data MBA: Driving Business strategies with Data Science. Nova Jersey: Wiley, 2015.

Aula 4
CUNHA NETO, F. Como funcionam os Sistemas de Controle de Versão (SCV). Cadernos CiComp, 26 jun. 2017.
Disponível em: [Link] Acesso em: 7 dez. 2021.

FREITAS, D. T. M. Análise Comparativa entre Sistemas de Controle de Versões. Dissertação (Mestrado em

Computação).

Instituto de Ciências Exatas, Universidade Federal de Juiz de Fora. Juiz de Fora, 2010.

MACHADO, J. N. A eficácia do controle de versão de software: o sistema distribuído. Revista Científica Semana
Acadêmica.

[Link] 34/35
07/08/2023, 16:41 REPOSITÓRIOS DE DADOS_U2

Fortaleza, ano MMXIX, n. 159, 20 mar. 2019. Disponível em: [Link] Acesso em: 24 set. 2021.

MURTA, L. G. P. Gerência de configuração no desenvolvimento baseado em componentes. Tese de

Doutorado. COPPE, Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2006.

SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003.

[Link] 35/35