RCS (Revision Control System) - Parte 1

O RCS (Revision Control System) gerencia várias revisões de arquivos. RCS automatiza o armazenamento, recuperação, registro, identificação e fusão de revisões. RCS é útil para texto que é revisado frequentemente, incluindo código-fonte, programas, documentação, gráficos, papéis e cartas de formulário.

RCS foi desenvolvido por Walter F. Tichy na Universidade de Purdue no início dos anos 80 - Artigo: RCS: Um sistema para controle de versão (1991).

O projeto do RCS é uma melhoria em relação ao seu predecessor: Sistema de Controle de Código-Fonte (SCCS). As melhorias incluem uma interface de usuário mais simples e armazenamento melhorado de versões para recuperação mais rápida. O RCS melhora o desempenho armazenando uma cópia inteira da versão mais recente e, em seguida, armazena diferenças reversas (chamadas "deltas"). O RCS usa o GNU Diffutils para encontrar as diferenças entre as versões.

Em cenários de usuário único, como arquivos de configuração de servidor ou scripts de automação, o RCS ainda pode ser a ferramenta de controle de revisão preferencial, pois é simples e nenhum repositório central precisa estar acessível para salvar as revisões. Isso faz com que seja uma ferramenta mais confiável quando o sistema está em condições extremas de manutenção. Além disso, os arquivos de backup salvos são facilmente visíveis para a administração para que a operação seja direta. No entanto, não há mecanismos de proteção embutidos contra adulteração (ou seja, os usuários que podem usar as ferramentas RCS para a versão de um arquivo também, por design, são capazes de manipular diretamente o arquivo de controle de versão correspondente) e isso está levando alguns administradores conscientes de segurança a considerar sistemas de controle de versão cliente/servidor que restringem a capacidade dos usuários para alterar os arquivos de controle de versão.

Fontes:
https://www.gnu.org/software/rcs/
https://en.wikipedia.org/wiki/Revision_Control_System

Unknown

0 comentários:

Apache Subversion - Parte 2

Neste post, daremos continuidade as características do SVN. Segundo a Apache Software Foundation, o Subversion existe para ser universalmente reconhecido e adotado como um sistema de controle de versão centralizado e de código aberto, caracterizado pela sua confiabilidade como um refúgio seguro para dados valiosos; a simplicidade de seu modelo e uso; e sua capacidade de suportar as necessidades de uma grande variedade de usuários e projetos, desde indivíduos até grandes operações corporativas. O mais recente release foi lançado em 29-11-2016 com a versão 1.9.5. 

Camadas 

Internamente, um sistema Subversion compreende várias bibliotecas dispostas como camadas. Cada um executa uma tarefa específica e permite que os desenvolvedores criem suas próprias ferramentas no nível desejado de complexidade e especificidade.  
  • Fs - O nível mais baixo. Ele implementa o sistema de arquivos versionado que armazena os dados do usuário. 
  • Repos - Responsável pelo repositório construído em torno do sistema de arquivos. Ele tem muitas funções auxiliares e lida com os vários "ganchos" que um repositório pode ter, por exemplo, scripts que são executados quando uma ação é executada. Juntos, Fs e Repos constituem a "interface do sistema de arquivos".  
  • Mod_dav_svn - Fornece acesso WebDAV / Delta-V através do Apache 2.  
  • Ra - Gerencia o "acesso ao repositório", tanto local quanto remoto. Deste ponto em diante, os repositórios são consultados usando URLs, p. 
    • File: /// path / para acesso local, 
    • Http: // host / path / ou https: // host / path / para acesso WebDAV, ou 
    • Svn: // host / caminho / ou svn + ssh: // host / caminho / para o protocolo SVN.  
  • Cliente, Wc - O nível mais alto. Ele abstrai o acesso ao repositório e fornece tarefas comuns do cliente, como autenticar usuários ou comparar versões. Os clientes do Subversion usam a biblioteca Wc para gerenciar a cópia de trabalho local. 

Sistema de arquivos

Pode-se ver o sistema de arquivos do Subversion como "bidimensional". Duas coordenadas são usadas para endereçar inequivocamente itens do sistema de arquivos:
  • Path (caminho normal do sistema de arquivos para sistemas operacionais baseados em Unix); 
  • Revisão. 
Fonte: https://en.wikipedia.org/wiki/Apache_Subversion#/media/File:Svn_3D-tree.svg
Cada revisão em um sistema de arquivos do Subversion tem sua própria raiz, que é usada para acessar o conteúdo nessa revisão. Os arquivos são armazenados como links para a alteração mais recente; Assim, um repositório do Subversion é bastante compacto. O sistema consome espaço de armazenamento proporcional ao número de alterações feitas, não ao número de revisões. 
O sistema de arquivos do Subversion usa transações para manter as alterações atômicas. Uma transação opera em uma revisão especificada do sistema de arquivos, não necessariamente a mais recente. A transação tem sua própria raiz, na qual são feitas alterações. Em seguida, é confirmada e torna-se a última revisão, ou é interrompida. A transação é na verdade um objeto de sistema de arquivos de longa duração. Um cliente não precisa comprometer ou abortar uma transação em si, mas  também pode iniciar uma transação, sair e, em seguida, pode reabrir a transação e continuar usando-a. Potencialmente, vários clientes podem acessar a mesma transação e trabalhar juntos em uma alteração atômica, embora nenhum cliente existente exponha essa capacidade.

Ramificação e marcação

O Subversion usa o modelo de ramificação entre arquivos da Perforce para implementar ramificações e etiquetagem. Um ramo é uma linha separada de desenvolvimento. A marcação refere-se a rotular o repositório em um determinado ponto no tempo para que ele possa ser facilmente encontrado no futuro. No Subversion, a única diferença entre ramos e tags é como eles são usados.
Fonte: https://en.wikipedia.org/wiki/Apache_Subversion#/media/File:Subversion_project_visualization.svg
Um novo ramo ou tag é configurado usando o comando "svn copy", que deve ser usado no lugar do mecanismo do sistema operacional nativo. O diretório copiado é vinculado ao original no repositório para preservar seu histórico, e a cópia leva muito pouco espaço extra no repositório. 
Todas as versões em cada ramo mantêm o histórico do arquivo até o ponto da cópia mais quaisquer alterações feitas desde então. Pode-se "fundir" mudanças de volta para o tronco ou entre ramos.

Limitações e problemas

O Um problema conhecido no Subversion afeta a implementação da operação de renomeação de arquivo e diretório. A partir da atualização em 2014, o Subversion implementa a renomeação de arquivos e diretórios como uma "cópia" para o novo nome seguido de uma "exclusão" do nome antigo. Somente os nomes mudam, todos os dados relacionados ao histórico de edição permanecem os mesmos, e o Subversion ainda usará o nome antigo nas revisões mais antigas da "árvore". No entanto, o Subversion pode tornar-se confuso quando uma alteração conflita com edições feitas em outro lugar, tanto para commits regulares, quanto para fusão ramos.

A versão do Subversion 1.5 abordou alguns desses cenários, enquanto outros permaneceram problemáticos. O lançamento do Subversion 1.8 abordou alguns desses problemas ao fazer movimentos de primeira classe no cliente, mas ainda é tratado como copy + delete no repositório.
A partir de 2013 atualização, o Subversion não possui alguns recursos de administração e gerenciamento de repositório. Por exemplo, alguém pode querer editar o repositório para remover permanentemente todos os registros históricos de determinados dados. Subversion não tem suporte embutido para conseguir isto de forma simples.
O Subversion armazena cópias adicionais de dados na máquina local, o que pode se tornar um problema com projetos ou arquivos muito grandes, ou se os desenvolvedores trabalharem em vários ramos simultaneamente. Nas versões anteriores a 1.7, os diretórios .svn no lado do cliente poderiam ficar corrompidos por atividades mal desenvolvidas do usuário, como operações globais de busca/substituição. A partir da versão 1.7, o Subversion usa uma única pasta .svn centralizada por área de trabalho.
O Subversion não armazena os tempos de modificação dos arquivos. Isso pode não ser sempre o que é esperado. Para mitigar isso, existem ferramentas de terceiros que permitem preservar o tempo de modificação e outros meta-dados do sistema de arquivos. No entanto, dar check-out em arquivos de uma data atual, também é importante.
O Subversion usa um modelo de controle de revisão centralizado. Ben Collins-Sussman, um dos criadores do Subversion, acredita que um modelo centralizado ajudaria a evitar que programadores inseguros ocultassem seu trabalho de outros membros da equipe. Alguns usuários de sistemas de controle de versão consideram o modelo centralizado como prejudicial, o famoso, Linus Torvalds atacou o modelo do Subversion e seus desenvolvedores.
O Subversion muitas vezes não lida bem com a normalização de nome de arquivo executada pelo sistema de arquivos HFS +, o que pode causar problemas quando arquivos com caracteres acentuados em seus nomes são adicionados ao repositório.

Desenvolvimento e implementação

A CollabNet continuou seu envolvimento com o Subversion, mas o projeto funciona como uma comunidade de código aberto independente. Em novembro de 2009, o projeto foi aceito na Incubadora Apache, com o objetivo de se tornar parte dos esforços da Apache Software Foundation. Desde março de 2010, o projeto é formalmente conhecido como Apache Subversion, sendo uma parte do Apache Top-Level Projects.

Em outubro de 2009, a WANdisco anunciou a contratação de compromissos básicos do Subversion já que a empresa passou a se tornar um dos principais patrocinadores corporativos do projeto. Isso incluiu Hyrum Wright, presidente da Subversion Corporation e gerente de lançamento do projeto Subversion desde o início de 2008, que se juntou à empresa para liderar sua equipe de código aberto.

A comunidade de código-fonte aberto do Subversion não fornece binários, mas os usuários potenciais podem fazer o download de binários de voluntários. Embora o projeto Subversion não inclua uma interface gráfica oficial do usuário (GUI) para uso com o Subversion, terceiros desenvolveram um  número de diferentes GUIs, juntamente com uma ampla variedade de software adicional auxiliar.

O trabalho anunciado em 2009 incluiu o SubversionJ (uma API Java) e a implementação do comando Obliterate, semelhante ao fornecido pela Perforce. Ambos os aprimoramentos foram patrocinados pela WANdisco.

Os committers do Subversion normalmente têm, pelo menos, um ou dois novos recursos em desenvolvimento ativo ao mesmo tempo. A versão 1.7 do Subversion em outubro de 2011 incluiu um transporte HTTP simplificado para melhorar o desempenho e uma biblioteca de cópia de trabalho reescrita.

Referências


https://en.wikipedia.org/wiki/Apache_Subversion
http://directory.fsf.org/wiki/Subversion
https://subversion.apache.org/

Rafael Reis

0 comentários:

Sistema de Controle de Código-Fonte (SCCS) - Parte 1



O Sistema de Controle de Código-Fonte (SCCS) é um sistema de controle de versão inicial, voltado para o código-fonte do programa e outros arquivos de texto. Foi originalmente desenvolvido em SNOBOL, Bell Labs, em 1972 por Marc Rochkind para um computador IBM System / 370 rodando OS / 360 MVT. Foi mais tarde reescrito por ele em C para UNIX, em seguida, executando em um PDP-11, e lançado com a edição do Programmer Workbench (PWB) desse sistema operacional.Subsequentemente, o SCCS foi incluído nas distribuições comerciais de Sistema nas versões III e V da AT & T. Não foi licenciado com 32V, o antepassado de Berkeley Unix.
 
O conjunto de comandos SCCS agora faz parte da especificação UNIX única.O SCCS era o sistema de controle de versão dominante para Unix até que sistemas de controle de versão mais recentes, notadamente o RCS (Revision Control System) e posterior CVS, fossem adotados de forma mais generalizada. Hoje, esses sistemas de controle de versões iniciais são geralmente considerados obsoletos, particularmente na comunidade de código aberto, que em grande parte abraçou sistemas de controle de versão distribuídos. No entanto, o formato de arquivo SCCS ainda é usado internamente por alguns programas de controle de versão mais recentes, incluindo BitKeeper e TeamWare. Este último é um frontend para SCCS. Sablime foi desenvolvido a partir de uma versão modificada do SCCS, mas usa um formato de arquivo de histórico que é incompatível com SCCS. 
 
O formato de arquivo SCCS usa uma técnica de armazenamento chamada delta intercalada (ou o weave). Esta técnica de armazenamento é agora considerada por muitos desenvolvedores de sistemas de controle de versão como fundações avançadas para técnicas de fusão e controle de versão, como o merge do "Precise Codeville" ("pcdv").Além de corrigir alguns problemas do ano 2000 em 1999, não há desenvolvimento ativo nas várias versões de SCCS específicas de fornecedores do UNIX. Em 2006, a Sun Microsystems (hoje parte da Oracle Corporation) lançou sua versão Solaris do SCCS como código aberto sob a Licença de Desenvolvimento e Distribuição Comum como parte de seus esforços para o código aberto do Solaris.

O SCCS consiste em duas partes: comandos SCCS e arquivos SCCS. Todas as operações básicas (por exemplo, criar, apagar, editar) podem ser realizadas por comandos SCCS. Arquivos SCCS têm um único formato com o prefixo s., que poderia ser facilmente controlado por comandos SCCS.

Fontes:
https://en.wikipedia.org/wiki/Source_Code_Control_System
http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.genprogc/sccs.htm

Unknown

0 comentários:

Gestão de Projetos: Redmine (Parte 1)



O Redmine é uma aplicação web de gerenciamento de projetos flexível. Escrito usando a estrutura Ruby on Rails, é multiplataforma e pode ser integrado com múltiplos bancos de dados. É de código aberto e está sob os termos da GNU General Public License v2 (GPL).

Neste post vamos abordar algumas das principais características deste sistema:

Suporte a projetos múltiplos
  • Gerencie todos os seus projetos com uma instância do Redmine;
  • Cada usuário pode ter um papel diferente em cada projeto;
  • Cada projeto pode ser declarado como público (visível por qualquer pessoa) ou privado (visível somente pelos membros do projeto);
  • Módulos (por exemplo, wiki, repositório, rastreamento de problemas, ...) podem ser ativados / desativados em nível de projeto. 

Suporte a vários subprojetos
  • Gerenciar partes do projeto relacionadas como subprojetos de um projeto principal.

Controle de acesso flexível baseado em funções
  • Defina seus próprios papéis e defina suas permissões em um clique.
http://www.redmine.org/screenshots/role_permissions.png


Sistema de rastreamento de problemas flexível

  • Definir seus próprios status e tipos de problemas;
  • As transições de fluxo de trabalho podem ser configuradas para cada tipo de problema e função através da interface de administração baseada na Web (uma configuração padrão pode ser carregada ao instalar o aplicativo).



Gráfico e calendário de Gantt
  • Gantt automático e calendário com base nas datas de início e de vencimento dos problemas. 

Funcionalidade de rastreamento de tempo
  • O tempo pode ser inserido no nível do projeto ou do bilhete;
  • Relatório simples para visualizar o tempo por usuário, tipo de problema, categoria ou atividade.

 
Os campos personalizados
  • Você pode definir seus próprios campos personalizados para problemas, entradas de horário, projetos e usuários;
  • Formatos diferentes estão disponíveis: texto, data, boolean, números inteiros, listas drop-down e caixas de verificação;
  • Campos personalizados podem ser exibidos na lista de problemas e usados como filtros, como campos regulares.

Continua na próxima postagem...


Fonte : Redmine <http://www.redmine.org/projects/redmine/wiki/Features>

Maryellen

2 comentários:

Apache Subversion - Parte 1

Apache Subversion (frequentemente abreviado SVN, depois de seu nome de comando svn) é um sistema de controle de versão e revisão de software distribuído como código aberto sob a Licença Apache. Os desenvolvedores de software usam o Subversion para manter versões atuais e o histórico de arquivos como código-fonte, páginas da Web e documentação. Seu objetivo é ser um sucessor compatível com o Sistema de Versões Concorrentes (CVS), amplamente utilizado.



A comunidade de código aberto tem utilizado amplamente o Subversion em vários projetos, tais como: Projetos da Apache Software Foundation, Free Pascal, FreeBSD, GCC, Mono e SourceForge. CodePlex oferece acesso ao Subversion, bem como a outros tipos de clientes.

O Subversion foi criado pela CollabNet Inc. em 2000 e agora é um projeto de alto nível do Apache sendo construído e usado por uma comunidade global de colaboradores.

Características


As principais características do Apache Subversion são:

  • Os diretórios são versionados.
  • Cópia, exclusão e renomeação são versionados.
  • Metadados versionados de forma livre ("propriedades").
  • Commits Atômicos.
  • Ramificação e marcação são operações baratas (tempo constante).
  • Acompanhamento de mesclagem.
  • Bloqueio de arquivos.
  • Os links simbólicos podem ser versionados.
  • Sinalizador executável é preservado.
  • Opção de servidor de rede Apache, com protocolo WebDAV / DeltaV.
  • Opção de servidor autônomo (svnserve).
  • Saída analisável.
  • Mensagens localizadas.
  • Resolução de conflitos interativos.
  • Repositório somente leitura espelhamento.
  • Escrever através de proxy sobre WebDAV.
  • Nativo cliente / servidor, projeto de biblioteca em camadas com APIs limpas.
  • Arquivos binários manipulados de forma eficiente.
  • Os custos são proporcionais ao tamanho da mudança, não ao tamanho dos dados.
  • Ligações a linguagens de programação.
  • Changelists (Listas de mudança - Tradução livre).
  • Dois tipos de armazenamento de repositório: FSFS e FSX.


Acesso ao repositório


O acesso aos repositórios do Subversion pode ser feito por:
  1. Sistema de arquivos local ou sistema de arquivos de rede, acessado diretamente pelo cliente. Este modo usa o esquema de acesso de caminho file: ///.
  2. WebDAV / Delta-V (usando http ou https) usando o módulo mod_dav_svn para o Apache 2. Este modo usa o esquema de acesso http: // host / caminho ou https: // host / caminho para conexões seguras usando ssl.
  3. Protocolo "svn" personalizado (porta padrão 3690), usando texto simples ou sobre TCP / IP. Esse modo usa o esquema de acesso svn: // host / caminho para transporte não criptografado ou svn + ssh: // esquema host / caminho para tunelamento sobre ssh.
Todos os três meios podem acessar tanto repositórios FSFS e Berkeley DB (depreciado). Além disso, qualquer versão 1.x de um cliente pode trabalhar com qualquer servidor 1.x. Os clientes e servidores mais novos têm recursos adicionais e recursos de desempenho, mas têm suporte de fallback para clientes / servidores mais antigos.

Referências


https://en.wikipedia.org/wiki/Apache_Subversion
http://directory.fsf.org/wiki/Subversion
https://subversion.apache.org/

Unknown

0 comentários:

O que é Controle de Versão?

Mas o que é controle de versão? Para explicarmos este conceito utilizaremos das definições de um dos mais famosos sistema de controle de versão, que se chama Git. O Git é um sistema de controle de versão de documentos e código fonte inicialmente desenvolvido para o núcleo do sistema operacional Linux e que acabou sendo utilizado por muitos outros projetos. O Git é um sistema distribuído e, por isso, não depende de um servidor central para estar funcionando. Nele, é possível ter acesso ao histórico de todo um diretório, bem como o controle de versão dos arquivos lá contidos. Isso é tudo que precisamos saber sobre o Git hoje. Vamos ao que é essa "onda" de controle de versão.




Git logo
Logo do Git

Podemos classificar os sistemas de controle de versão em três tipos:

    I    - Sistemas de Controle de Versão Locais;
    II  - Sistemas de Controle de Versão Centralizados;
    III - Sistemas de Controle de Verão Distribuídos.

Vamos a cada um deles!

Sistema de Controle de Versão Local

Talvez seja um dos mais comuns e o cara que vai fazer a gente entender os sistemas de controle de versão. O controle de versão local, é quando se faz o controle de arquivos que precisam passar por diversas alterações em um ou mais diretórios: renomeando, classificando por datas, organizando em pastas e/ou subpastas. Aí a pessoa pode pensar "Ah! então é isso mesmo que eu faço nos meus projetos e o que estou fazendo é o controle de versão." a resposta é que sim, não é a forma mais recomendada por ser muito suscetível a erros, principalmente se você não for muito organizado.
Se hoje em dia isso ainda é comum, imagina nos primórdios... Mas também existem sistemas para organizar e efetuar o controle de versões de um arquivo na própria máquina. Esses sistemas de controle de versão local ou VCS (Version Control System), foram desenvolvidos justamente para sanar o problema dos desorganizados e dar uma força aos organizados. Um dos mais populares é o sistema chamado RCS que é um sistema que ainda é muito utilizado e faz parte de pacotes de desenvolvimento disponibilizados pelo Mac OS X que habilita este comando quando é instalado. O comando rcs é responsável por criar patches com a diferença dos arquivos, permitindo a recriação do mesmo quando se junta todos os patches.

Diagrama do Controle de Versionamento Local

Sistema de Controle de Versão Centralizado

Depois de superado o problema dos desorganizados localmente, podemos imaginar que existe também a necessidade de controlar arquivos que sabemos que mais de uma pessoa deve ter acesso e ajudar na sua construção. Como fazer isso? Basta centralizar em um local! E isso implica também em ser organizado, já que é mais de uma pessoa tentando organizar um arquivo no mesmo local. Então... Os sistemas de controle de versão centralizados ou CVCS (Centralized Version Control System) são os sistemas que permitem o acesso ao histórico e versões de um arquivo que está sendo trabalhado em colaboração. Não é difícil de imaginar. Nesses sistemas existe um servidor que contém todos os arquivos e versões de forma centralizada e os envolvidos podem fazer downloads e uploads das alterações e o servidor faz todo o controle.


Diagrama do Controle de Versionamento Centralizado

Sistema de Controle de Versão Distribuídos

Ainda assim, mesmo depois do sistema de controle de versionamento centralizado, alguns outros problemas foram logo percebidos. É tudo centralizado não, é? É! Todos tem acesso, não tem? Tem! Então, qual o problema?! A centralização! É, dizer que a centralização é um problema é um pouco de exagero de nossa parte, até por que pode sim existir servidores muito bem planejados e implementados a ponte da chance de der problema na máquina seja mínima, maaaaas... Pode acontecer, não pode? Pode! Para resolver essa problemática onde pode ser que os servidores centralizados tenha um disco danificado ou qualquer outro problema onde pode vim a impossibilitar o acesso e a integridade dos arquivos, vieram os sistemas de controle de versão distribuídos ou DVCS (Distributed Version Control System). Nesses, são envolvidos muito mais que um servidor e existe a sincronização entre eles para que haja a garantia de que se um der problema, os arquivos estão a salvo e íntegros sempre. Para o usuário, nada muda, é como se fosse um único servidor ou serviço, principal característica dos sistemas distribuídos.

 
Diagrama do Controle de Versão Distribuído











Entenderam? :)


Fonte: https://git-scm.com/book/pt-br/v1/Primeiros-passos-Sobre-Controle-de-Vers%C3%A3o


Unknown

1 comentários:

Ferramentas de Planejamento de Software, uma visão geral

Resultado de imagem para desenvolvimento de software  
Fonte: KeepSolutions


Um gerenciamento eficaz tem se tornado de fundamental importância para se obter sucesso no desenvolvimento de software. O desenvolvimento de software é uma atividade complexa, envolvendo inúmeros fatores que são imprevisíveis e de difícil controle, como volatilidade dos requisitos e prazos. Fatores como esses, fazem com que o produto final não atenda às expectativas ou, até mesmo, às necessidades do cliente, além de exceder o prazo e o orçamento previsto.

Para evitar que o produto final não atenda às expectativas ou, até mesmo, às necessidades do cliente, além de exceder o prazo e o orçamento previsto, é necessário que um projeto de software seja bem sucedido. Para isto, existem parâmetros, como por exemplo, o escopo do software, os riscos, os recursos necessários às tarefas a serem realizadas, entre outros.

Quando se aplica o gerenciamento de projetos ao desenvolvimento de um projeto de software, é importante que o gerente e a equipe visualizem todo o processo. O uso de ferramentas de gestão de projetos torna-se indispensável para garantir resultados positivos no desenvolvimento de um projeto, pois permite saber quais métodos e processos de trabalhos são utilizados, e visualizar informações em tempo real ao alcance de toda a equipe envolvida.

É preciso conhecer os recursos tecnológicos de cada ferramenta e analisar as reais necessidades da implantação de acordo com o projeto. Softwares de Planejamento e Controle, não são apenas fazedores de cronogramas, mas poderosos gerenciadores de redes de planejamento, por isso é necessário o entendimento da extensão de suas possibilidades.

Fonte: Ferramentas para Gestão de Projetos - Revista Engenharia de Software Magazine 45. Disponível em: <http://www.devmedia.com.br/ferramentas-para-gestao-de-projetos-revista-engenharia-de-software-magazine-45/23563>.

Maryellen

2 comentários:

Uma Breve História do Controle de Versão

Existem dezenas de Sistemas de Controle de Versão (SCVs), desde os proprietários até os de código aberto. Esse pequeno texto tem por objetivo descrever uma sucinta história dividindo-os em três gerações.

A primeira geração 

A característica comum comum da primeira geração de SCVs era que eles eram todos orientados a arquivos e centralizados. A maioria estava baseada em bloqueio, com os sistemas baseados em fusões (merging). 

Os sistemas de controle de versão são vagamente derivados de sistemas de gerenciamento de mudanças e de registro usados ​​em mainframes na década de 1960. É interessante notar que o primeiro SCV, enquanto mais tarde tornou-se estreitamente associado com o sistema operacional Unix, foi escrito originalmente em um computador IBM System/370 com o sistema operacional MVT. 

SCCS (Source Code Control System) foi o primeiro SCV, escrito em 1972 por Marc Rochkind, um dos primeiros desenvolvedores do Unix no Bell Labs. O SCCS tinha como características: bloqueio, orientado a arquivos e centralizado. Na verdade, não tinha suporte para repositórios remotos (em rede), uma capacidade que nem sequer era imaginada até a ascensão pós-1982 da Internet. 

RCS (Revision Control System) foi o segundo SCV a ser construído e o mais antigo ainda em uso - fontes indicam que uma terceira versão foi lançada em 1983, não havendo fontes que documentem versões anteriores. Assim como o SCCS, para o qual foi uma resposta direta, RCS é bloqueante, baseado em arquivo e centralizado sem capacidade para acesso à rede. 

O DSEE (Domain Software Engineering Environment) era um VCS com recursos significativos do SCM, incluindo um mecanismo de compilação e um rastreador de tarefas, lançado pela primeira vez em 1984 em estações de trabalho do Apollo Domain. Depois que a Apollo foi adquirida pela HP em 1989, a DSEE continuou a ser utilizada extensivamente na HP. A equipe DSEE tornou-se Atria, renomeando DSEE para ClearCase. Mais tarde, a Atria foi adquirida pela IBM e continua a ser amplamente utilizada em 2008 sob o nome Rational ClearCase.
 

A segunda geração

Diferentemente da primeira geração, essa nova geração veio com algumas melhorias através do uso de redes centralizadas, uso de multi-arquivos e  merge (fusão) antes do commit (envio). 

Dick Grune, professor da Universidade Livre de Amsterdã, escreveu alguns scripts wrappers de roteiro em torno de RCS em 1984-1985 para resolver problemas relacionados a desenvolvimento colaborativo e escalabilidade. Dois anos depois, Brian Berliner transformou esses scripts em programas em C que se tornaram a base para versões posteriores do que ficou conhecido como o Sistema de Versões Concorrentes (RCS).

Em 2000, um grupo que incluía alguns desenvolvedores anteriores do CVS lançou o Subversion, um projeto que visava explicitamente melhorar e substituir o CVS. O Subversion também é conhecido como SVN, depois do nome do diretório que seus repositórios usam convencionalmente. Embora a sua primeira produção oficial não tenha chegado até 2004, os betas de aproximadamente 2002 em diante foram utilizáveis. Na verdade, o projeto iria ter sucesso em seus principais objetivos bem antes da versão 1.0 enviada.

A terceira geração 

Os SVNs de terceira geração são nativamente descentralizados, ocorre o commit antes do merge e as operações são armazenadas em changesets (conjunto de mudanças). Há muitos projetos concorrentes neste espaço: BitKeeper, git, monotone, darcs, Mercurial e bzr, são alguns dos mais conhecidos

Para complementar, um pequeno vídeo mostrando a linha do tempo dos controles de versão desde 1972 até 2012.



Referências

http://www.catb.org/~esr/writings/version-control/version-control.html#history

http://ericsink.com/vcbe/html/history_of_version_control.html

Unknown

0 comentários:

Sejam bem vindos!


Olá! Pessoal, esse é o mais novo blog da turma de Gerência de Projetos, período 2016.2 da Universidade Federal de Sergipe (UFS) ministrada pelo docente Rogério Patrício C. do Nascimento.

Somos alunos do curso de Sistemas de Informação e através deste Edu-Blog publicaremos informações para serem discutidas acerca da disciplina, do curso e Universidade. Daremos ênfase neste Edu-Blog ao que diz respeito sobre Ferramentas de Planejamento e Sistemas de Controle de Versão, tema este que apresentaremos seminário ao final da disciplina.

Acompanhem o Edu-Blog e fiquem por dentro de todas as pesquisas desenvolvidas pelo grupo e também sobre o andamento das atividades práticas que envolvem a Lacertae SW (empresa fictícia).

E como diria o nosso ilustríssimo professor:


Rafael Reis

0 comentários:

Assinar: Postagens (Atom)