Como usar o SVN, Branch? Tag? Tronco?

Eu estava pesquisando um pouco no Google e não consegui encontrar um bom guia para iniciantes do SVN , não no significado de "como eu uso os comandos"; Como controle meu código-fonte?

O que eu gostaria de esclarecer são os seguintes tópicos:

• Com que frequência você se compromete? Tantas vezes quanto se pressiona Ctrl+ s?
• O que é um Branch e o que é um Tag e como você os controla?
• O que entra no SVN? Apenas o código-fonte ou você compartilha outros arquivos aqui também? (Não são considerados arquivos com versão ..)

Eu não tenho idéia do que ramo e tag é, então não conheço o objetivo, mas meu palpite é que você carrega coisas no tronco e, quando faz uma construção importante, move-o para o ramo? Então, o que é considerado uma compilação importante nesse caso?

O livro do subversion é uma excelente fonte de informações sobre estratégias para organizar seu repositório, ramificação e marcação.

Veja também:

Você continua o desenvolvimento em uma filial ou no tronco

Estratégias de ramificação

Fiz as mesmas perguntas quando implementamos o Subversion aqui - cerca de 20 desenvolvedores espalhados por 4 a 6 projetos. Não encontrei nenhuma fonte boa com '' a resposta ''. Aqui estão algumas partes de como nossa resposta se desenvolveu nos últimos 3 anos:

- comprometer-se quantas vezes for útil; nossa regra prática é confirmada sempre que você fizer um trabalho suficiente para que seja um problema precisar refazê-lo se as modificações forem perdidas; às vezes eu cometo a cada 15 minutos mais ou menos, outras vezes pode levar dias (sim, às vezes leva um dia para escrever uma linha de código)

- usamos ramos, como sugeriu uma de suas respostas anteriores, para diferentes caminhos de desenvolvimento; No momento, para um de nossos programas, temos 3 ramos ativos: 1 para o desenvolvimento principal, 1 para o esforço ainda não concluído de paralelizar o programa e 1 para o esforço de revisá-lo para usar arquivos de entrada e saída XML;

- dificilmente usamos tags, embora pensemos que devemos usá-las para identificar lançamentos na produção;

Pense no desenvolvimento prosseguindo por um único caminho. Em algum momento ou estado do desenvolvimento, o marketing decide liberar a primeira versão do produto, para que você plante uma bandeira no caminho rotulado '1' (ou '1.0' ou o que você tem). Em algum outro momento, alguma faísca brilhante decide paralelizar o programa, mas decide que isso levará semanas e que as pessoas querem seguir o caminho principal nesse meio tempo. Então você constrói uma bifurcação no caminho e pessoas diferentes vagam pelos diferentes garfos.

As bandeiras na estrada são chamadas de 'etiquetas' e os garfos na estrada são onde os 'galhos' se dividem. Ocasionalmente, também, os galhos se reúnem.

- colocamos todo o material necessário para criar um executável (ou sistema) no repositório; Isso significa pelo menos código-fonte e arquivo de criação (ou arquivos de projeto para o Visual Studio). Mas quando temos ícones e arquivos de configuração e todas essas outras coisas, isso entra no repositório. Alguma documentação encontra seu caminho no repositório; certamente qualquer documentação, como arquivos de ajuda que possam ser parte integrante do programa, é um local útil para colocar a documentação do desenvolvedor.

Até colocamos executáveis ​​do Windows para nossos lançamentos de produção, para fornecer um local único para quem procura software - nossos lançamentos do Linux vão para um servidor, portanto, não precisam ser armazenados.

- não exigimos que o repositório seja sempre capaz de fornecer uma versão mais recente que construa e execute; alguns projetos funcionam dessa maneira, outros não; a decisão cabe ao gerente do projeto e depende de muitos fatores, mas acho que ela falha ao fazer grandes alterações em um programa.

* How often do you commit? As often as one would press ctrl + s?

O mais frequente possível. O código não existe, a menos que esteja sob controle de origem :)

As confirmações frequentes (depois de conjuntos de alterações menores) permitem integrar suas alterações facilmente e aumentar as chances de não quebrar nada.

Outras pessoas observaram que você deve confirmar quando tiver um pedaço de código funcional, no entanto, acho útil confirmar um pouco mais frequentemente. Algumas vezes, notei que uso o controle de origem como um mecanismo rápido de desfazer / refazer.

Quando trabalho em meu próprio ramo, prefiro comprometer o máximo possível (literalmente, sempre que pressiono ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Leia o livro SVN - é um lugar que você deve começar quando aprender SVN:

• O que é uma filial?
• Tag

* What goes into the SVN?

Documentação, pequenos binários necessários para compilação e outras coisas que têm algum valor vão para o controle de origem.

Aqui estão alguns recursos sobre frequência de confirmação, mensagens de confirmação, estrutura do projeto, o que colocar sob controle de origem e outras diretrizes gerais:

• Práticas recomendadas de controle de versão (meu próprio blog)
• Check-in mais cedo, check-in com frequência (Coding Horror) (os comentários aqui contêm muitos bons conselhos)
• Política de consolidação do KDE

Essas perguntas do Stack Overflow também contêm algumas informações úteis que podem ser do seu interesse:

• Organizando a base do código-fonte ao misturar duas ou mais linguagens (como Java e C ++)
• Sugestões para uma boa mensagem de confirmação: formato / orientação?
• Quantas vezes confirmar alterações no controle de origem?
• Aprendendo o controle de versão e aprendendo bem

Com relação aos conceitos básicos do Subversion, como ramificação e marcação, acho que isso está muito bem explicado no livro do Subversion .

Como você deve perceber, depois de ler um pouco mais sobre o assunto, as opiniões das pessoas sobre as melhores práticas nessa área são muitas vezes variadas e às vezes conflitantes. Eu acho que a melhor opção para você é ler sobre o que as outras pessoas estão fazendo e escolher as diretrizes e práticas que você acha que fazem mais sentido para você.

Não acho que seja uma boa idéia adotar uma prática se você não entender o propósito dela ou não concordar com a lógica por trás dela. Portanto, não siga cegamente nenhum conselho, mas decida-se sobre o que você acha que funcionará melhor para você. Além disso, experimentar diferentes maneiras de fazer as coisas é uma boa maneira de aprender e descobrir como você gosta de trabalhar. Um bom exemplo disso é como você estrutura o repositório. Não existe uma maneira certa ou errada de fazer isso, e muitas vezes é difícil saber de que maneira você prefere até que você realmente os experimente na prática.

A frequência de confirmação depende do seu estilo de gerenciamento de projetos. Muitas pessoas se abstêm de confirmar se isso interromperá a compilação (ou funcionalidade).

As ramificações podem ser usadas de duas maneiras, normalmente: 1) Uma ramificação ativa para desenvolvimento (e o tronco permanece estável) ou 2) ramificações para caminhos de desenvolvimento alternativos.

As tags geralmente são usadas para identificar lançamentos, para que não se percam na mistura. A definição de 'release' é com você.

Eu acho que o principal problema é que a imagem mental do controle de origem está confusa. Geralmente temos tronco e ramificações, mas depois temos idéias não relacionadas de tags / lançamentos ou algo que afete.

Se você usar a idéia de uma árvore mais completamente, ela se torna mais clara, pelo menos para mim é.

Temos o tronco -> forma ramos -> produz frutos (tags / releases).

A ideia é que você expanda o projeto a partir de um tronco, que cria ramificações quando o tronco estiver estável o suficiente para retê-lo. Então, quando o galho produzir uma fruta, você o arrancará e soltará como uma etiqueta.

Tags são essencialmente entregas. Enquanto tronco e galhos os produzem.

Como já foi dito, o SVN Book é o melhor lugar para começar e uma ótima referência depois de conseguir as pernas do mar. Agora, para suas perguntas ...

Com que frequência você se compromete? Tantas vezes quanto se pressiona ctrl + s?

Freqüentemente, mas não com a freqüência que você pressiona ctrl + s. É uma questão de gosto pessoal e / ou política da equipe. Pessoalmente, eu diria confirmar quando você concluir um pedaço de código funcional, por menor que seja.

O que é um Branch e o que é um Tag e como você os controla?

Primeiro, o tronco é onde você faz seu desenvolvimento ativo. É a linha principal do seu código. Uma ramificação é um desvio da linha principal. Pode ser um desvio importante, como um lançamento anterior, ou apenas um pequeno ajuste que você deseja experimentar. Uma tag é uma captura instantânea do seu código. É uma maneira de anexar um rótulo ou marcador a uma revisão específica.

Também vale a pena mencionar que na subversão, tronco, ramificações e tags são apenas convenções. Nada impede você de trabalhar em tags ou ter ramificações que são sua linha principal ou desconsiderar o esquema tag-branch-trunk completamente. Mas, a menos que você tenha uma boa razão, é melhor seguir a convenção.

O que entra no SVN? Apenas o código-fonte ou você compartilha outros arquivos aqui também?

Também uma escolha pessoal ou em equipe. Prefiro manter qualquer coisa relacionada à compilação no meu repositório. Isso inclui arquivos de configuração, scripts de criação, arquivos de mídia relacionados, documentos, etc. Você não deve fazer o check-in de arquivos que precisam ser diferentes na máquina de cada desenvolvedor. Você também não precisa fazer o check-in de subprodutos do seu código. Estou pensando principalmente em criar pastas, arquivos de objetos e coisas do gênero.

Eric Sink, que apareceu no podcast SO nº 36 em janeiro de 2009, escreveu uma excelente série de artigos sob o título Como fazer controle de fonte .

(Eric é o fundador da SourceGear que comercializa uma versão compatível com plug-in do SourceSafe, mas sem a horribilidade.)

Apenas para adicionar outro conjunto de respostas:

• Comprometo sempre que termino um trabalho. Às vezes, é uma pequena correção de bug que muda apenas uma linha e leva dois minutos para fazer; outras vezes, são duas semanas de suor. Além disso, como regra geral, você não confirma nada que interrompa a compilação. Portanto, se você levou muito tempo para fazer alguma coisa, pegue a versão mais recente antes de confirmar e veja se suas alterações quebram a compilação. É claro que, se passo muito tempo sem cometer, fico desconfortável porque não quero perder esse trabalho. No TFS, eu uso essa coisa legal como "prateleiras" para isso. No SVN, você terá que trabalhar de outra maneira. Talvez crie sua própria ramificação ou faça backup desses arquivos manualmente em outra máquina.
• Ramos são cópias de todo o seu projeto. A melhor ilustração para seu uso é talvez a versão dos produtos. Imagine que você está trabalhando em um projeto grande (por exemplo, o kernel do Linux). Após meses de suor, você finalmente chegou à versão 1.0 lançada ao público. Depois disso, você começa a trabalhar na versão 2.0 do seu produto, que será muito melhor. Mas nesse meio tempo também há muitas pessoas por aí que estão usando a versão 1.0. E essas pessoas encontram bugs que você precisa corrigir. Agora, você não pode corrigir o erro na próxima versão 2.0 e enviá-lo aos clientes - ele não está pronto. Em vez disso, você deve retirar uma cópia antiga da fonte 1.0, corrigir o erro e enviá-lo para as pessoas. É para isso que servem os ramos. Quando você lançou o 1. Na versão 0, você criou uma ramificação no SVN que fez uma cópia do código-fonte naquele momento. Este ramo foi nomeado "1.0". Em seguida, você continuou o trabalho na próxima versão em sua cópia de origem principal, mas a cópia 1.0 permaneceu lá como estava no momento do lançamento. E você pode continuar corrigindo erros lá. Tags são apenas nomes anexados a revisões específicas para facilitar o uso. Você poderia dizer "Revisão 2342 do código fonte", mas é mais fácil referir-se a ela como "Primeira revisão estável". :)
• Eu costumo colocar tudo no controle de origem que se relaciona diretamente com a programação. Por exemplo, como estou criando páginas da Web, também coloco imagens e arquivos CSS no controle de origem, sem mencionar os arquivos de configuração, etc. A documentação do projeto não entra lá, no entanto, isso é apenas uma questão de preferência.

Outros afirmaram que isso depende do seu estilo.

A grande questão para você é com que frequência você "integra" seu software. No desenvolvimento orientado a testes, o Agile e o Scrum (e muitos outros) dependem de pequenas mudanças e integração contínua. Eles pregam que pequenas mudanças são feitas, todo mundo encontra os intervalos e os corrige o tempo todo.

No entanto, em um projeto maior (pense em governo, defesa, 100k + LOC), você simplesmente não pode usar a integração contínua, pois isso não é possível. Nessas situações, pode ser melhor usar a ramificação para fazer muitas pequenas confirmações, mas trazer de volta para o tronco APENAS o que funcionará e está pronto para ser integrado à compilação.

Uma ressalva é que, se eles não forem gerenciados adequadamente, pode ser um pesadelo no seu repositório obter trabalho no tronco, pois todos estão desenvolvendo a partir de pontos diferentes no tronco (que é, aliás, um dos maiores argumentos para integração contínua).

Não há resposta definitiva para essa pergunta, a melhor maneira é trabalhar com sua equipe para encontrar a melhor solução de comprometimento.

O Controle de Versão com Subversion é o guia para iniciantes e veteranos.

Eu não acho que você possa usar o Subversion efetivamente sem ler pelo menos os primeiros capítulos disso.

Para confirmar, eu uso as seguintes estratégias:

• cometer o mais rápido possível.

• Cada alteração / correção de recurso deve ter sua própria confirmação (não confirme muitos arquivos de uma vez, pois isso tornará o histórico desse arquivo impreciso - por exemplo, se eu alterar um módulo de log e um módulo da GUI de forma independente e confirmar os dois ao mesmo tempo, ambas as alterações serão visíveis nos dois históricos de arquivos. Isso dificulta a leitura de um histórico de arquivos),

• não quebre a compilação em nenhum commit - deve ser possível recuperar qualquer versão do repositório e compilá-lo.

Todos os arquivos necessários para criar e executar o aplicativo devem estar no SVN. Arquivos de teste e outros não devem, a menos que façam parte dos testes de unidade.

Muitos bons comentários aqui, mas algo que não foi mencionado são as mensagens de confirmação. Estes devem ser obrigatórios e significativos. Especialmente com ramificação / fusão. Isso permitirá que você acompanhe quais alterações são relevantes para quais recursos de bugs.

por exemplo, o svn commit . -m 'bug #201 fixed y2k bug in code'dirá a qualquer um que olhar para o histórico para que serve essa revisão.

Alguns sistemas de rastreamento de erros (por exemplo, trac) podem procurar essas mensagens no repositório e associá-las aos tickets. O que facilita muito a elaboração de quais alterações estão associadas a cada ticket.

A política em nosso trabalho é a seguinte (equipe de vários desenvolvedores trabalhando na estrutura orientada a objetos):

• Atualize do SVN todos os dias para obter as alterações do dia anterior

• Comprometa-se diariamente para que, se você estiver doente ou ausente no (s) dia (s) seguinte (s), alguém mais possa assumir o controle de onde você parou.

• Não comprometa o código que quebra nada, pois isso afetará os outros desenvolvedores.

• Trabalhe em pequenos pedaços e se comprometa diariamente COM COMENTÁRIOS SIGNIFICATIVOS!

• Como equipe: mantenha uma ramificação de desenvolvimento e mova o código de pré-lançamento (para o controle de qualidade) para uma ramificação de produção. Essa ramificação deve sempre ter código totalmente funcional.

O Manual TortoiseSVN TSVN é baseado no livro de subversão , mas disponível em muito mais idiomas.

Eu acho que há duas maneiras de cometer frequência:

1. Confirme com muita frequência, para cada método implementado, pequena parte do código, etc.
2. Confirme apenas partes do código concluídas, como módulos etc.

Eu prefiro o primeiro - porque usar o sistema de controle de origem é muito útil não apenas para o projeto ou empresa, mas antes de tudo é útil para o desenvolvedor. Para mim, o melhor recurso é reverter todo o código enquanto procura a melhor implementação de tarefa atribuída.