SVN Workflow - frango antes do ovo - Antes de mesclar V1 com V2, preciso de código de V1 para trabalhar na v2

Question

Nossa equipe distribuída (3 desenvolvedores internos e mais de 3 desenvolvedores externos) usa o SVN para gerenciar nossa base de código para um site. Temos uma filial para cada versão menor (4.1.0, 4.1.1, 4.1.2, etc ...). Temos um porta -malas na qual mesclamos cada versão quando fazemos um lançamento e publicamos em nosso site.

Um exemplo do problema que estamos tendo é assim: um novo recurso é adicionado, vamos chamá -lo de "capacidade de criar um projeto" para 4.1.1. Outro recurso que depende de um em 4.1.1 está programado para entrar em 4.1.2, chamado "Capacidade de adicionar tarefas aos projetos".

Então, na segunda -feira, dizemos que 4.1.1 está 'fechado' e precisa ser testado. Nossos desenvolvedores remotos geralmente começam a trabalhar em recursos/ingressos para 4.1.2 neste momento. Ao longo da semana, testaremos 4.1.1 e corrigiremos todos os bugs e os comprometeremos em 4.1.1. Então, na sexta -feira, mais ou menos, marcaremos 4.1.1, mesclaremos com o porta -malas e, finalmente, mesclaremos com 4.1.2. Mas, nos 4-5 dias que estamos testando, 4.1.2 não possui o código de 4.1.1 de que alguns dos novos recursos para 4.1.2 dependem.

Portanto, um desenvolvedor que está adicionando a "capacidade de adicionar tarefas aos projetos" não possui o recurso "Capacidade de criar um projeto" para construir e precisa fazer algumas travessuras de cópia de arquivo para poder continuar trabalhando nele .

O que poderia/devemos fazer para suavizar esse processo?

PS Desculpas se essa pergunta foi feita antes - eu fez Pesquise, mas não consegui encontrar o que estou procurando.

Answer 1

A maneira como fazemos é que tudo O desenvolvimento acontece no tronco. Você só se compromete com o Trunk e depois quaisquer correções necessárias para 4.1.1 se fundir a partir de porta-malas para a ramificação 4.1.1. A filial para 4.1.2 é criada apenas ao testar em 4.1.2 começa - uma vez que a filial 4.1.2 for feita, o trabalho continua no tronco e, se for necessária correções para 4.1.2, elas são feitas no tronco e depois mescladas em 4.1.2.

É muito raro que fizemos uma mudança em um ramo que precisa ser mesclado de volta no porta -malas (ou em qualquer outro lugar, na verdade).

Answer 2

Parece que você precisa de uma filial X com base no tronco e uma ramificação y com base em x.

Você pode desenvolver um recurso em X e começar a testá -lo. Enquanto isso, você copia x para uma nova ramificação Y e desenvolve o segundo recurso lá.

Eventualmente, X é fundido para o Trunk e liberado. Então, quando terminar de trabalhar em Y, você pode mesclá -lo de volta ao X para testar e depois no porta -malas para liberação.

Você pode repetir esse processo depois que os dois recursos forem lançados. Na próxima vez que você terminar um recurso em X, e deseja desenvolvê -lo, basta mesclá -lo de volta para Y.

Se você está fazendo isso, é importante lembrar:

• Você faz mesclas normais do tronco para X e de X para Y.
• Você reintega as mescladas de X de volta ao porta -malas e de Y de volta para X.
• Depois de uma reintegração se fundir no porta -malas, você precisa bloquear o compromisso de ser fundido de volta ao X.
• Após uma reintegração se fundir em X, você precisa bloquear o compromisso de ser fundido de volta em Y.
• Mantenha notas detalhadas sobre qual recurso está em qual ramo; Caso contrário, isso pode ficar confuso rapidamente.

Answer 3

Eu teria todos os novos começos entrar no porta -malas, a menos que haja um motivo para colocá -los em outro lugar. Ao criar ramificações diferentes para 4.1.1 e 4.1.2, por exemplo, seu exemplo é melhor abordado por mesclagem entre ramos, os quais podem ser mesclados de volta ao tronco. Que nojo! Isso é o inferno Mergeinfo, na minha opinião.

Aqui estão alguns conselhos básicos do Livro de Subversão:

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

Answer 4

Eu acho que existem várias maneiras de fazer isso.

Mas pratico que o porta -malas seja sempre estável. Nenhum código inacabado e instável deve entrar no porta -malas. Se houver um novo recurso a ser adicionado e leva dias, talvez semanas, eu crio uma filial para ele. Quando é feito, e o ramo parece estável e testado, ele é fundido no porta -malas novamente e o ramo é excluído.

Dessa forma, o porta -malas permanecerá estável. E o código experimental é sempre o ramo.

Se eu, por algum motivo, mudar de idéia e pular um projeto meio feito, não preciso pensar no porta -malas. Eu simplesmente excluo o ramo ....

Answer 5

Uma abordagem é o ramo 4.1.2 de 4.1.1 em vez de do tronco (e, claro 4.1.1 do tronco).

Em seguida, você pode mesclar facilmente 4.1.1 em 4.1.2 regularmente e ainda poder fazer a mesclagem trivial de volta ao porta -malas para cada ramo quando chegar a hora de liberar.