0b10

Github foi lançado em 2008. Se a sua carreira de engenharia de software, como a minha, não é mais velha que o Github, então o Git pode ser o único software de controle de versões que você já usou. Enquanto as pessoas às vezes discutem sobre sua curva de aprendizagem íngreme ou interface unintuitiva, Git tornou-se o go-to de todos para o controle de versão. InStack Overflow em 2015, 69,3% dos entrevistados usaram o Git, quase duas vezes mais do que o sistema de controle de versões mais popular,Subversion.1 Depois de 2015, Stack Overflow parou de perguntar aos desenvolvedores sobre os sistemas de controle de versão que eles usam, talvez porque o Git se tornou tão popular que a pergunta era desinteressante.

Git em si não é muito mais velho do que Github. Linus Torvalds lançou a primeira versão do Git em 2005. Embora hoje os desenvolvedores mais jovens possam ter um hard timeconceiving de um mundo onde o termo “software de controle de versão” não significava mais ou menos Git, tal mundo não existia há muito tempo. Havia muitas alternativas para escolher. Os desenvolvedores de código aberto preferiram Subversion, empresas e empresas de jogos eletrônicos usados Perforce (alguns ainda o fazem), enquanto o projeto do kernel do theLinux contava com um sistema de controle de Versão chamado kitkeeper.alguns destes sistemas, particularmente o BitKeeper, podem se sentir familiares a um usuário youngGit transportado de volta no tempo. A maioria não o faria. BitKeeper aparte, os sistemas de controle de Version que vieram antes do Git funcionaram de acordo com um paradigma fundamentalmente diferente. Em uma taxonomia oferecida por Eric Sink, autor do controle de versão, por exemplo, o Git é um sistema de controle de versão de terceira geração, enquanto que mais dos antecessores do Git,os sistemas populares nos anos 90 e início dos anos 2000, são sistemas de controle de versão de segunda geração.2 Quando os sistemas de controlo de versão de terceira geração são distribuídos, os sistemas de controlo de versão de segunda geração são centralizados. Você quase certamente já ouviu Git descrito como um sistema de controle de Versão” Distribuído ” antes. Eu nunca entendi bem a distinção distribuida / centralizada, pelo menos não até que eu instalei eexperimentei com um sistema centralizado de controle de versão de segunda geração.

o sistema que instalei foi CVS. CVS, abreviatura de Concurrent Versions System, foi o primeiro sistema de controle de versões de segunda geração. Foi também o sistema de controle de versão mais popular por cerca de uma década até ser substituído em 2000 pelo Subversion. Mesmo assim, Subversion era suposto ser “CVS but better”, o que apenas sublinha como o CVS dominante se tornou ao longo da década de 1990.

CVS foi desenvolvido pela primeira vez em 1986 por um cientista da computação holandês chamado Dick Grune,que estava procurando uma maneira de colaborar com seus alunos em um projeto de compilador.3 CVS foi inicialmente pouco mais do que uma coleção de SCRIPTSWRAPPING RCS shell (sistema de controle de Revisão), um sistema de controle de versão de primeira geração que Grune queria melhorar. RCS funciona de acordo com um modelo pessimista, o que significa que dois programadores não podem trabalhar em um único arquivo desde então. A fim de editar um arquivo, você tem que primeiro pedir RCS para um bloqueio exclusivo do arquivo, que você mantém até que você esteja terminado de editar. Se mais alguém já está a editar um ficheiro que precisa de editar, terá de esperar. O CVS melhorou os RCS e introduziu na segunda geração de sistemas de controlo de versões, trocando o modelo de bloqueio de modelo semelhante por um modelo optimista. Programadores poderiam agora editar o mesmo arquivo ao mesmo tempo, fundindo suas edições e resolvendo qualquer conflito. (Brian Berliner, um engenheiro que mais tarde assumiu o projeto CVS, escreveu um artigo muito legível sobre as inovações do CVS em 1990.)

nesse sentido, o CVS não era assim tão diferente do Git, que também funciona de acordo com um modelo otimista. Mas é aí que as semelhanças acabam. Inact, when Linus Torvalds was developing Git, one of his guiding principles wasWWCVSND, or ” What Would CVS Not Do.”Sempre que ele estava em dúvida sobre uma decisão,ele se esforçou para escolher a opção que não tinha sido escolhida no projeto de vc.4 Assim, embora o CVS anteceda o Git por mais de uma década, influenciou o Git como um tipo de modelo negativo.eu realmente gostei de brincar com o CVS. Acho que não há melhor maneira de entender porque a natureza distribuída do Git é uma melhoria em relação ao que aconteceu antes. Por isso, convido-vos a virem comigo numa viagem emocionante e gastarem os próximos dez minutos da vossa vida a aprender sobre um pedaço de softwarenobody usado na última década. (Ver correcção.)

começar com CVS

instruções para instalar CVS podem ser encontradas na página do projeto. Em MacOS, você pode instalar CVS usingHomebrew.

Uma vez que o CVS é centralizado, ele distingue entre o universo do lado cliente e o universo do lado servidor de uma maneira que algo como o Git não faz. A distinção não é tão pronunciada que existem diferentes executáveis. Mas para começar a usar CVS, mesmo em sua própria máquina, você terá que configurar a infra-estrutura do CVS.

a infra-estrutura CVS, a loja central para todo o seu código, é chamada de repositório.Enquanto no Git você normalmente teria um repositório para cada projeto, no CVS o repositório detém todos os seus projetos. Existe um repositório central para tudo, embora existam formas de trabalhar apenas com um projecto de cada vez.

para criar um repositório local, você executa o comando init. Faria isto num sítio global como o seu directório.

$ cvs -d ~/sandbox init

CVS permite que você lhe passe opções para o cvs comando próprio ou para oinit subcomando. As opções que aparecem após o comando cvs são de natureza global, enquanto as opções que aparecem após o subcomand são específicas do Sub-comando. Neste caso, a bandeira-d é global. Aqui acontece dizer CVs onde queremos criar o nosso repositório, mas em geral o -d flag aponta para a localização do repositório que queremos usar para qualquer ação dada. Ele pode ser ideal para fornecer a bandeira o tempo todo, de modo que o ambientvariável pode ser definido em vez disso.

desde que estamos trabalhando localmente, acabamos de passar um caminho para o nosso argumento -d, mas também poderíamos ter incluído um hostname.

o comando cria uma pasta chamada sandbox na sua pasta pessoal. Se você listar o conteúdo de sandbox, você vai descobrir que ele contém outro diretor chamado . Este diretório, para não ser confundido com o ambientevariável, possui arquivos administrativos para o repositório.Parabéns! Acabou de criar o seu primeiro repositório CVS.

verificando no código

digamos que você decidiu manter uma lista de suas cores favoritas. Você é uma pessoa artisticamente inclinada, mas extremamente esquecida. Que tipo de backup de sua lista de cores e salvá-lo como um arquivo chamado favorites.txt:

blueorangegreendefinitely not yellow

Vamos também assumir que você já salvou seu arquivo em um novo diretório chamadocolors. Agora você gostaria de colocar sua lista de cores favoritas sob controle de versão, Porque daqui a 50 anos será interessante olhar para trás e ver como seus gostos mudaram com o tempo.

para isso, terá de importar o seu directório como um novo CVSproject. Você pode fazer isso usando o comando import :

$ cvs -d ~/sandbox import -m "" colors colors initialN colors/favorites.txtNo conflicts created by this import

Aqui estamos especificando a localização do nosso repositório com o -d flagagain. The remaining arguments are passed to the import subcomand. Temos de enviar uma mensagem, mas aqui não precisamos de uma, por isso deixámos a mensagem bloqueada. O próximo argumento, colors, especifica o nome do nosso novo diretório no repositório; aqui acabamos de usar o mesmo nome que o diretório em que estamos.Os dois últimos argumentos especificam a tag do fornecedor e a tag de lançamento, respectivamente.Falaremos mais sobre etiquetas num minuto.

acabou de puxar o seu projecto “colors” para o repositório CVS. Existem diferentes formas de levar o código para o CVS, mas este é o método recomendado pelo Pragmatic Version Control UsingCVS, o Pragmatic Programmer book about CVS. O que torna este método um pouco desajeitado é que você tem que verificar o seu trabalho fresco, mesmo que você já tem um existing colors diretório. Em vez de usar esse diretório, você vai apagá-lo e, em seguida, confira a versão que o CVS já sabe sobre:

$ cvs -d ~/sandbox co colorscvs checkout: Updating colorsU colors/favorites.txt

subcomand:

é aqui que as coisas começam a parecer alienígenas. O CVS não tem objetos de commit. No ponto anterior, existe algo chamado de “identificador de Commit”, mas esta pode ser apenas uma edição relativamente recente-nenhuma menção de um” identificador de Commit ” aparece no controle de versão empragmático usando CVS, que foi publicado em 2003. (O lastupdate para CVS foi lançado em 2008.5)

Considerando que com Git você falaria sobre a versão de um arquivo associado com com commit45de392, em arquivos CVS são versionados separadamente. A primeira versão do seu ficheiro é a versão 1.1, a próxima versão é a 1.2, e assim por diante. Quando os ramos estão envolvidos, os números extras são adicionados, então você pode acabar com algo como o 1.1.1.1 acima, que parece ser o padrão em nosso caso, mesmo que não tenhamos criado quaisquer ramos.

Se você fosse executar cvs log (equivalente a git log) em um projeto com lotsof arquivos e compromete-se, você verá um histórico individual para cada arquivo. Você tem um arquivo na versão 1.2 e um arquivo na Versão 1.14 no mesmo projeto.

Let’s go ahead and make a change to version 1.1 of our favorites.txt file:

 blue orange green+cyan definitely not yellow

Depois que fizemos a mudança, podemos executar o cvs diff para ver o que o CVS pensa que’vedone:

CVS reconhece que nós adicionamos uma nova linha que contém a cor “ciano” para thefile. (Na verdade, diz que fizemos mudanças no arquivo “RCS”; você pode ver que os scvs nunca escaparam totalmente de sua Associação original com RCS.) The diff we arebining shown is the diff between the copy of favorites.txt in our workingdirectory and the 1.1.1.1 version stored in the repository.

A fim de atualizar a versão armazenada no repositório, temos que enviar o thechange. No Git, este seria um processo em várias etapas. Teríamos de encenar a mudança para que ela apareça no nosso índice. Depois, cometeríamos a mudança. Finalmente, para tornar a mudança visível para qualquer outra pessoa, teríamos que empurrar o commit para o repositório de origem.

no CVS, todas estas coisas acontecem quando você executa cvs commit. CVS justbundles up all the changes it can find and puts them in the repository:

i’m so used to Git that this looks as terrible. Sem uma oportunidade para encenar mudanças, qualquer coisa velha que você tocou em seu diretor de trabalho pode acabar como parte do repositório público. Você passivo-agressivamente reescreveu a função mal implementada de um colega de trabalho por necessidade catártica,nunca pretendendo que ele soubesse? Que pena, ele agora acha que és um idiota. Você também não pode editar seus commits antes de pressioná-los, uma vez que um commit é um push. Você passa 40 minutos repetindo repetidamente git rebase -i até que o seu histórico local de commit flua como a derivação de uma prova matemática? Desculpe, não pode fazer isso aqui, e todos vão descobrir que não escreve os seus testes primeiro.

mas eu também agora entendo por que tantas pessoas acham git desnecessariamente complicado.Se cvs commit é o que você estava acostumado, então eu tenho certeza que encenar e mudar de estilo lhe pareceria uma tarefa inútil.

Quando as pessoas falam sobre Git sendo um sistema “distribuído”, esta é principalmente a diferença que eles significam. No CVS, você não pode fazer commits localmente. Um commit é umaubissão de código para o repositório central, então não é algo que você possa obter sem uma conexão. Tudo o que tem aqui é o seu directório de trabalho. No Git, você tem um repositório local completo, de modo que você pode fazer commits durante todo o dia, enquanto desligado. E você pode editar esses commits, revert, branch, andcherry escolher o quanto quiser, sem que mais ninguém tenha que saber.

Uma vez que os commits eram um negócio maior, os usuários do CVS muitas vezes os faziam raramente.Os Commits conteriam tantas mudanças como hoje poderíamos esperar ver no pedido de atração aten-commit. Isto foi especialmente verdadeiro se commits ativou um CIbuild e uma suíte de teste automatizada.

agora, Se corremos cvs status, podemos ver que temos uma nova versão do nosso arquivo:

Mesclar

Como mencionado acima, no CVS, você pode editar um arquivo que alguém está alreadyediting. Foi a grande melhoria do CVS em relação ao RCS. O que acontece quando você precisa voltar a juntar as suas mudanças?digamos que você convidou alguns amigos para adicionar suas cores favoritas à sua lista. Enquanto eles estão adicionando suas cores, você decide que você não mais gosta da cor verde e removê-lo da lista.

Quando vai enviar as suas alterações, poderá descobrir que o CVS notifica um problema:

parece que os seus amigos cometeram as suas alterações primeiro. Então sua versão defavorites.txt não está atualizada com a versão no repositório. Se o seuun cvs status, verá que a sua cópia local de favorites.txt é version1. 2 com algumas alterações locais, mas a versão do repositório é 1.3:

Você pode executar cvs diff para ver exatamente quais são as diferenças entre 1.2 e 1.2.3:

parece que os nossos amigos realmente gostam de rosa. Em qualquer caso, eles editaram uma parte diferente do arquivo do que nós, de modo que as mudanças são fáceis de mesclar. CVScan fazer isso por nós quando executar o cvs update, que é semelhante a git pull:

$ cvs updatecvs update: Updating .RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,vretrieving revision 1.2retrieving revision 1.3Merging differences between 1.2 and 1.3 into favorites.txtM favorites.txt

Se você der uma olhada em: favorites.txt você vai descobrir que ele tem beenmodified para incluir as alterações que seus amigos fizeram para o arquivo. As tuas mudanças também lá estão. Agora você está livre para enviar o arquivo:

o resultado final é o que você obteria no Git executando git pull --rebase. As tuas mudanças foram acrescentadas para além das mudanças dos teus amigos. Não existe “mergecommit”.”

às vezes, mudanças no mesmo arquivo podem ser incompatíveis. Se os teus amigos tivessem trocado “verde” por “olive”, por exemplo, isso teria entrado em conflito com a tua mudança ao remover “verde”. Nos primeiros dias do CVS, este era exatamente o tipo de caso que fazia com que as pessoas se preocupassem que o CVS não era seguro.; O bloqueio dissimulado do RCS assegurou que tal caso nunca poderia surgir. Mas a Cvsguarantia a segurança, certificando-se de que as mudanças de ninguém são escritas de forma automática. Tem de dizer ao CVS qual a alteração que deseja continuar, por isso, quando executar o cvs update, o CVS marca o ficheiro com ambas as alterações da mesma forma que o Git faz quando o Git detecta um conflito de junção. Você então tem que editar manualmente o arquivo e escolher a mudança que você deseja manter.

a coisa interessante a notar aqui é que os conflitos de junção têm de ser corrigidos para que você possa enviar. Esta é outra consequência do CVS’ centralizado nature.In Git, você não tem que se preocupar em resolver se funde até que você empurre os comitês que você tem localmente.

Tags and Branches

Uma vez que o CVS não tem objetos de commit facilmente endereçáveis, a única maneira de coletar as alterações do groupa é marcar um determinado estado de diretório de trabalho com o atag.

a Criação de uma marca é fácil:

$ cvs tag VERSION_1_0cvs tag: Tagging .T favorites.txt

Você pode ser capaz de retornar arquivos para este estado com cvs update andpassing a tag -r bandeira:

$ cvs update -r VERSION_1_0cvs update: Updating .U favorites.txt

tag que você poderia usar mais tarde se o therefactor deu errado. As pessoas também usaram tags se quisessem generateproject-wide diffs. Basicamente, todas as coisas que fazemos rotineiramente hoje com com commithashes têm que ser antecipadas e planejadas com CVS, uma vez que você precisava ter as tags disponíveis já.

ramificações podem ser criadas no CVS. Ramos são apenas um tipo especial oftag:

$ cvs rtag -b TRY_EXPERIMENTAL_THING colorscvs rtag: Tagging colors

Que só cria a filial (em plena vista de todos, por sinal), de modo youstill precisa mudar para que o uso de cvs update:

$ cvs update -r TRY_EXPERIMENTAL_THING

Os comandos acima alternar para a nova filial em sua atual workingdirectory, mas Pragmática de Controle de Versão Usando o CVS, na verdade, aconselha-se a que youcreate um novo diretório para manter o seu novo ramo. Presumivelmente os seus autores encontraram directórios mais fáceis do que mudar de ramificações no CVS.

Pragmatic Version Control Using CVS also advises against creating branchesoff of an existing branch. Eles recomendam apenas a criação de ramos fora do ramo da linha, que no Git é conhecido como master. Em geral, a ramificação foi considerada uma habilidade” avançada ” do CVS. No Git, você pode iniciar um novo branch foralmost qualquer razão trivial, mas no CVS branching foi tipicamente usado apenas quando estritamente necessário, como para lançamentos.

uma ramificação poderia ser posteriormente fundida de volta à linha principal usando cvs update e -j flag:

$ cvs update -j TRY_EXPERIMENTAL_THING

Obrigado pela Cometer Histórias

Em 2007, Linus Torvalds deu atalk sobre Git no Google. O Git era muito novo então, então a palestra foi basicamente uma tentativa de persuadir uma sala cheia de programadores epíclicos de que eles deveriam usar o Git, mesmo que o Git fosse tão diferente de qualquer coisa então disponível. Se ainda não viste a conversa, encorajo-te a vê-la. O Linus é um orador divertido, mesmo que o henever não seja o seu ” eu ” descarado. Ele faz um excelente trabalho de explicar por que o modelo distribuído de controle de versão é melhor do que o centralizado. Muitas de suas críticas são reservadas para o CVS em particular.

Git é uma ferramenta complexa. Aprender Pode ser uma experiência estimulante. Mas também estou continuamente espantado com as coisas que o Gitcan faz. Em comparação, o CVS é simples e direto, embora muitas vezes impossível de fazer muitas das operações que agora tomamos como garantidas. Voltar atrás e usar CVS por um tempo é uma excelente maneira de encontrar-se com uma nova apreciação esquecer o poder e flexibilidade. Ilustra bem Por que razão a compreensão da história do desenvolvimento de software pode ser tão benéfica—recolher e reexaminar as ferramentas soletas ensinar-lhe-á volumes sobre o porquê por detrás das ferramentas que hoje utilizamos.Se gostou deste post, mais parece que sai a cada quatro semanas! Siga @TwoBitHistory no Twitter ou subscreva o RSS feed para ter certeza de que você sabe quando um novo post está fora.

Correction

i’ve been told that there are many organizations, particularly risk-adverseorganizations that do things like make medical device software, that still useCVS. Programadores nessas organizações desenvolveram pequenos truques para trabalhar em torno das limitações do CVS, tais como fazer um novo branch para quase todas as mudanças para evitar se comprometer diretamente com HEAD. (Graças a Michael Kohne por descobrir isso.)