Recurso de estratégia de ramificação do Subversion vs. release
Esta documentação foi escrita para descrever a série 1.7.x do Apache ™ Subversion®. Se você estiver executando uma versão diferente do Subversion, você é fortemente encorajado a visitar o svnbook / e, em vez disso, consultar a versão desta documentação apropriada para sua versão do Subversion.
Padrões de ramificação comuns.
Há muitos usos diferentes para ramificação e svn merge, e esta seção descreve os mais comuns.
O controle de versão é mais frequentemente usado para desenvolvimento de software, então aqui está uma rápida olhada em dois dos padrões mais comuns de ramificação / fusão usados por equipes de programadores. Se você não estiver usando o Subversion para desenvolvimento de software, fique à vontade para pular esta seção. Se você é um desenvolvedor de software que usa o controle de versão pela primeira vez, preste muita atenção, pois esses padrões geralmente são considerados práticas recomendadas por pessoas experientes. Esses processos não são específicos do Subversion; eles são aplicáveis a qualquer sistema de controle de versão. Ainda assim, pode ser útil vê-los descritos em termos do Subversion.
Liberar filiais.
A maioria dos softwares tem um ciclo de vida típico: codificar, testar, liberar, repetir. Existem dois problemas com este processo. Primeiro, os desenvolvedores precisam continuar criando novos recursos, enquanto as equipes de garantia de qualidade levam tempo para testar versões supostamente estáveis do software. Novo trabalho não pode parar enquanto o software é testado. Em segundo lugar, a equipe quase sempre precisa suportar versões mais antigas do software; Se um bug for descoberto no código mais recente, é mais provável que exista também nas versões lançadas, e os clientes desejarão obter essa correção de bug sem ter que esperar por uma nova versão importante.
Aqui é onde o controle de versão pode ajudar. O procedimento típico é assim:
Os desenvolvedores cometem todo o novo trabalho no tronco. As alterações do dia a dia são confirmadas no / trunk: novos recursos, correções de erros e assim por diante.
O tronco é copiado para uma ramificação "release". Quando a equipe acha que o software está pronto para ser lançado (digamos, uma versão 1.0), o / trunk pode ser copiado para /branches/1.0.
As equipes continuam a trabalhar em paralelo. Uma equipe inicia testes rigorosos do ramo de lançamento, enquanto outra equipe continua um novo trabalho (digamos, para a versão 2.0) em / trunk. Se os bugs forem descobertos em qualquer local, as correções serão transportadas para frente e para trás conforme necessário. Em algum momento, no entanto, até esse processo é interrompido. A ramificação está congelada para testes finais antes de uma liberação.
O ramo é marcado e liberado. Quando o teste estiver concluído, /branches/1.0 é copiado para /tags/1.0.0 como um instantâneo de referência. A tag é empacotada e liberada para os clientes.
A filial é mantida ao longo do tempo. Enquanto o trabalho continua em / trunk para a versão 2.0, correções de bugs continuam sendo portadas de / trunk para /branches/1.0. Quando consertos de bugs suficientes se acumulam, o gerenciamento pode decidir fazer uma versão 1.0.1: /branches/1.0 é copiado para /tags/1.0.1, e a tag é empacotada e liberada.
Todo esse processo é repetido à medida que o software amadurece: quando o trabalho do 2.0 é concluído, um novo branch de release 2.0 é criado, testado, marcado e, eventualmente, liberado. Depois de alguns anos, o repositório acaba com um número de ramificações de liberação em "manutenção" e um número de tags representando as versões finais enviadas.
Ramos de recursos.
Um branch de recursos é o tipo de branch que tem sido o exemplo dominante neste capítulo (aquele em que você está trabalhando enquanto Sally continua trabalhando / trunk). É uma ramificação temporária criada para trabalhar em uma alteração complexa sem interferir na estabilidade de / trunk. Ao contrário das ramificações do release (que talvez precisem ser suportadas para sempre), filiais de recursos nascem, são usadas por um tempo, mescladas de volta ao tronco e, finalmente, excluídas. Eles têm uma extensão finita de utilidade.
Mais uma vez, as políticas do projeto variam muito no que diz respeito exatamente quando é apropriado criar um ramo de recursos. Alguns projetos nunca usam ramificações de recursos: os commits para / trunk são gratuitos. A vantagem deste sistema é que é simples: ninguém precisa aprender sobre ramificação ou fusão. A desvantagem é que o código de tronco é muitas vezes instável ou inutilizável. Outros projetos usam ramificações ao extremo: nenhuma alteração é confirmada diretamente no tronco. Até mesmo as mudanças mais triviais são criadas em uma ramificação de curta duração, cuidadosamente revisadas e mescladas ao tronco. Em seguida, a ramificação é excluída. Este sistema garante um tronco excepcionalmente estável e utilizável em todos os momentos, mas ao custo de sobrecarga de processo tremenda.
A maioria dos projetos usa uma abordagem intermediária. Eles geralmente insistem que / trunk compile e passem os testes de regressão a todo momento. Um ramo de recurso é necessário apenas quando uma alteração requer um grande número de confirmações desestabilizadoras. Uma boa regra é fazer essa pergunta: se o desenvolvedor trabalhou por dias em isolamento e depois cometeu a grande alteração de uma só vez (para que / trunk nunca fosse desestabilizado), seria uma mudança muito grande para revisar? Se a resposta a essa pergunta for sim, a mudança deve ser desenvolvida em um ramo de recurso. Conforme o desenvolvedor confirma alterações incrementais na ramificação, elas podem ser facilmente revisadas pelos colegas.
Finalmente, há a questão de como manter um ramo de recursos em sincronia com o tronco à medida que o trabalho progride. Como mencionamos anteriormente, há um grande risco de trabalhar em um ramo por semanas ou meses; as trocas de tronco podem continuar a chegar, até o ponto em que as duas linhas de desenvolvimento diferem tanto que pode se tornar um pesadelo tentar mesclar o ramo de volta ao tronco.
É melhor evitar essa situação mesclando regularmente as alterações do tronco na filial. Crie uma política: uma vez por semana, mescle as alterações de tronco da última semana na agência.
Quando você estiver pronto para mesclar o ramo de recurso sincronizado de volta ao tronco, comece fazendo uma mesclagem final das alterações de tronco mais recentes na ramificação. Quando isso for feito, as versões mais recentes da ramificação e do tronco são absolutamente idênticas, exceto pelas alterações na ramificação. Você então mescla de volta com a opção --reintegrate:
Outra maneira de pensar sobre esse padrão é que sua sincronização semanal de tronco para filial é análoga à execução do svn update em uma cópia de trabalho, enquanto a etapa final de mesclagem é análoga à execução de svn commit de uma cópia de trabalho. Afinal, o que mais é uma cópia de trabalho, mas um ramo privado muito superficial? É um ramo capaz de armazenar apenas uma alteração por vez.
Você está lendo Controle de Versão com o Subversion (para o Subversion 1.7), por Ben Collins-Sussman, Brian W. Fitzpatrick e C. Michael Pilato.
Recurso de estratégia de ramificação do Subversion vs. release
Como estamos desenvolvendo em um sistema implantado, estamos tentando usar melhor as ramificações - Até recentemente, quase tudo era verificado no trunk, implantado para testar / testar e depois para produção. Isso significa que temos que ter muito cuidado durante o período de "Teste", e ainda assim, ocasionalmente, recebemos alterações indesejadas enviadas ao servidor com poucos testes.
Meu pensamento é que a melhor maneira seria os patches "secundários" irem direto ao tronco, os principais recursos se transformam em ramificações de recursos que são reintegrados no tronco quando completos e em uma ramificação "Produção" que sempre corresponde ao estado do servidor em que podemos mesclar implantação.
O principal benefício oferecido aqui é que você pode escolher quais mudanças serão lançadas na produção - se você quiser, pode pegar um único check-in ou filial e enviá-lo para a produção sem envolver todos os outros ramos.
Por outro lado, parece ser melhor ter filiais. Integre com o tronco frequentemente - faça mudanças para que elas não se acumulem e façam uma fusão desagradável.
Portanto, esses dois padrões podem levar ao caso em que você deseja mesclar uma ramificação com a Produção para trazer um recurso importante, mas essa ramificação já "inseriu" as alterações do tronco que você não deseja enviar.
O SVN pode lidar com isso? Existem práticas realmente boas que funcionam para grupos que desenvolvem código que é implantado a cada duas semanas?
Eu acho que tudo o que você descreve é possível com (uma versão atual como 1.7 ou 1.8 do Subversion). Aqui estão os passos a seguir:
Descreva suas estratégias de ramificação (e mesclagem). Você não pode misturar facilmente todos eles, e é difícil para os desenvolvedores saberem qual estratégia é usada onde, então a documentação e a comunicação estão aqui. Veja os seguintes recursos: Melhor estratégia de ramificação ao fazer integração contínua? Padrões comuns de ramificação Você usará o seguinte: Liberar ramificação para a liberação de produção, os patches são desenvolvidos diretamente lá. Para cada patch, você deve decidir se o patch deve estar disponível (no mesmo formulário) na próxima versão. Use o tronco para o desenvolvimento principal. Tudo o que você tem certeza de que estará no próximo lançamento deve ser desenvolvido no porta-malas. Não se fundir do tronco para (liberar) filial. Jamais!! Use as ramificações de recursos somente se você não tiver certeza se um recurso chegará à próxima versão. As ramificações de funcionalidades são (no Subversion) muito mais difíceis do que, e. no Git, então deve haver uma razão para usá-los. Mesclar todas as alterações do tronco para o ramo de recurso regularmente e apenas reintegrar no final, quando o recurso estiver integrado no tronco (para chegar à próxima versão). Encontre o ponto certo no tempo para fazer a ramificação e a mesclagem: Ramificação: Quando é necessário um branch de release estável (para integração com a próxima release), e quando o desenvolvimento pode começar para a seguinte release (então no trunk novamente)? Mesclagem: quando é o melhor momento para mesclar as alterações: Imediato, quando a alteração é recente; regularmente de vez em quando; (esperemos que não) apenas uma vez no final.
Suas filiais serão desenvolvidas ao longo do tempo assim:
Você começa com o tronco (e somente o tronco) para o lançamento 1.0, seu primeiro lançamento. Você ramifica o tronco, quando deseja fazer o teste de integração para o release 1.0 e inicia o desenvolvimento para o release 1.1 (no tronco). Você entrega o release 1.0 e fornece posteriormente patches diretamente do branch. Você ramifica o tronco, quando deseja fazer o teste de integração para o release 1.1 e inicia o desenvolvimento para o release 1.2 (ou 2.0) no tronco. . e assim por diante .
Ramificação e fusão do SVN Red Book explica tudo o que você precisa tecnicamente, mas não é tão claro como fazê-lo em diferentes contextos de negócios (minha opinião pessoal). Eu não encontrei um recurso que explica todas as opções e drivers por trás deles com detalhes suficientes.
Re: estratégia de ramificação - Feature vs Release.
Data: 2006-11-08 14:01:13 CET.
Esse é um ótimo tópico, parabéns por começar.
Na minha empresa, estamos usando svn e uma mistura de release e feature.
ramo. Estou tentando fazer com que funcione em uma estratégia de ramificação de lançamento.
Mas. temos 3/4 grandes aplicações. Os lançamentos são feitos por.
projeto, que adiciona um pouco de complexidade, como às vezes o mesmo.
aplicação é liberada em um prazo de 2/3 semanas, que então o.
mudanças precisam ser feitas em ambos os ramos de lançamentos e tronco, sim, a.
bagunça. :) Outro fator de complexidade é que armazenamos nossos JSP's em um.
repositório diferente, que então precisa sempre ser ramificado juntos.
Se não bastasse, todo o nosso código está espalhado na mesma raiz. Nós temos.
módulos refinados que são usados nas três aplicações, então o.
ramos são todos tirados da raiz.
Espero que tenhamos mais aplicativos separados, que incluam os JPSs.
e arquivos de configuração (os arquivos são armazenados em um terceiro repo :)) e.
seguindo uma abordagem de ramificação de lançamento consistente.
Minha pergunta, qual é a melhor abordagem de release / ramificação para esse tipo.
de lançamentos, que são feitos por projeto e não por aplicativo.
Em 08/11/06, Gundersen, Richard & lt; Richard. Gundersen & # 64; london-scottish & # 46; com & gt; escrevi:
& gt; Obrigado pela resposta, mas você tem o histórico completo de um arquivo, mesmo.
& gt; se foi ramificado. Toda vez que uma alteração é feita para esse arquivo, independentemente disso.
& gt; de qual ramificação a alteração foi feita, você recebe uma mensagem de log (desde que.
& gt; como o desenvolvedor escreve um).
& gt; Quando você finalmente mescla, você terá uma mensagem de log adicional.
& gt; dizendo algo como & quot; Mesclado de my_branch & quot ;, assim como todos os.
& gt; De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
& gt; Enviada: quarta-feira, 8 de novembro de 2006, 12:00 PM.
& gt; Assunto: Re: Estratégia de Ramificação - Feature vs Release.
& gt; Em 08/11/2006 às 5h06, Gundersen, Richard escreveu:
& gt; & gt; Nós estamos tendo um grande debate onde eu trabalho sobre se devo ou não usar o.
& gt; & gt; & quot; libertação & quot; com base em estratégia de ramificação, ou o "recurso" caminho baseado.
& gt; & gt; Eu sempre trabalhei com o último. Estas são as razões pelas quais:
& gt; & gt; 1) O tronco é sempre estável. Isso sempre imita exatamente o que está dentro
& gt; & gt; 2) Eu faço todo o trabalho novo em um ramo (seja pequeno.
& gt; & gt; mudança experimental ou uma nova versão que é essencialmente uma coleção.
& gt; & gt; de novos recursos). Isso para mim tem as seguintes vantagens adicionais.
& gt; & gt; uma. Minhas novas alterações não afetam a base de código de produção.
& gt; & gt; b. Quando o cliente que solicitou a alteração X deseja que ele seja ativado,
& gt; & gt; pode mesclá-lo no tronco (porque seu próprio ramo isolado) e.
& gt; & gt; liberar apenas essa mudança (mais o que quer que tenha sido originalmente no trunk). EU.
& gt; & gt; Cometê-lo, marcá-lo e ei pronto, o tronco ainda imita a produção.
& gt; & gt; exatamente. Com a abordagem baseada em release, com todo mundo comprometido.
& gt; & gt; mudanças diferentes para o tronco, quando um cliente quer mudar X para ir.
& gt; & gt; ao vivo, eu tenho que dizer a ele que pode ir viver, mas eu tenho que dizer.
& gt; & gt; cliente que, porque eu tenho que liberar X, sua mudança Y também deve ir.
& gt; & gt; viva também. Essa situação pode nunca ocorrer com sistemas que possuem um.
& gt; & gt; ciclo de vida de lançamento simples, mas quando você está lidando com sistemas grandes.
& gt; & gt; com diferentes conjuntos de clientes (especialmente se eles tiverem diferentes.
& gt; & gt; requisitos legais, ou eles estão em diferentes países) eu acho que isso.
& gt; & gt; Os argumentos contra essa abordagem são frequentemente:
& gt; & gt; 1) A fusão é difícil. Eu não gosto disso.
& gt; & gt; uma. Bem, na minha experiência com o Subversion e o CVS, a fusão é.
& gt; & gt; na verdade é bem fácil. Eu poderia ter alguns conflitos para resolver a cada momento.
& gt; & gt; e novamente, mas eles são geralmente muito fáceis de resolver, especialmente se.
& gt; & gt; manter meu ramo atualizado com o tronco (que pode ter tido algum.
& gt; & gt; 2) Manter o controle de muitos ramos é difícil.
& gt; & gt; uma. Na verdade não. Se eu usar uma convenção de nomenclatura boa, um punhado de.
& gt; & gt; Filiais são fáceis o suficiente para acompanhar. Não é como se eu fosse.
& gt; & gt; tem centenas de filiais para se preocupar, na realidade.
& gt; & gt; 3) Nós temos ramos de liberação para que você saiba exatamente o que está em um.
& gt; & gt; uma. Então, essa abordagem - o que quer que esteja no tronco está dentro
& gt; & gt; Produção. E, um ramo de lançamento, por definição, muda com o tempo.
& gt; & gt; é marcado como final após o qual ainda haverá um elemento de.
& gt; & gt; mesclagem envolvida para obtê-lo em sincronia com o ramo de desenvolvimento (tronco.
& gt; & gt; Eu posso ver porque as pessoas favoreciam a estratégia do ramo de lançamento, porque.
& gt; & gt; soa muito mais simples, mas acho que os benefícios do recurso.
& gt; & gt; abordagem superam os negativos. Eu espero que muitas pessoas o façam.
& gt; & gt; discordo de mim, mas é um bom debate e eu gostaria de receber qualquer comentário.
& gt; Um outro argumento em favor de fazer desenvolvimento no tronco e.
& gt; release from branches: Se você olhar o log de um arquivo, verá o arquivo.
& gt; histórico de alterações, não uma série de "muitas mudanças mescladas de foo.
& gt; & gt; Esta comunicação eletrônica é confidencial e exclusiva.
& gt; uso do destinatário. Pode conter privado e confidencial.
& gt; em formação. As informações, anexos e opiniões contidas neste documento.
& gt; E-mail é apenas do autor e não representa necessariamente.
& gt; os do London Scottish Bank PLC ou de quaisquer outros membros do London.
& gt; & gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
& gt; divulgação, distribuição ou posterior cópia ou uso desta comunicação.
& gt; ou a informação contida nela ou a tomada de qualquer ação com base nela. Se vocês.
& gt; tenha recebido esta comunicação por engano, por favor notifique a Informação.
& gt; Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
& gt; exclua a mensagem de todos os lugares no seu computador onde ela está armazenada.
& gt; & gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
& gt; segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
& gt; anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
& gt; resultante de qualquer corrupção ou alteração de dados ou importação de.
& gt; qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; & gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
& gt; razões. O London Scottish Bank PLC é regulado pelos Serviços Financeiros.
& gt; & gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Esta comunicação eletrônica é confidencial e para uso exclusivo do destinatário. Pode conter informações privadas e confidenciais. As informações, anexos e opiniões contidas neste e-mail são de seu autor e não representam necessariamente as do London Scottish Bank PLC ou de quaisquer outros membros do London Scottish Group.
& gt; Se você não for o destinatário pretendido, você está proibido de qualquer divulgação, distribuição ou cópia ou uso adicional desta comunicação ou das informações nela contidas ou de tomar qualquer medida com base nela. Se você recebeu esta comunicação por engano, por favor notifique o Gerente de Segurança da Informação na ISM & # 64; London-Scottish & # 46; com o mais rápido possível e exclua a mensagem de todos os lugares em seu computador onde ela está armazenada.
& gt; Utilizamos software de varredura de vírus, mas não podemos garantir a segurança das comunicações eletrônicas, e é recomendável que você verifique se há vírus em anexos. Não nos responsabilizamos por qualquer perda resultante de qualquer corrupção ou alteração de dados ou importação de qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; As respostas a este e-mail podem ser monitoradas por motivos operacionais ou comerciais. O London Scottish Bank PLC é regulado pela Financial Services Authority.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
& gt; Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Recebido em Wed Nov 8 14:02:07 2006.
Esta mensagem: [Corpo da mensagem] Próxima mensagem: Duncan Murdoch: "Re: Estratégia de Ramificação - Versao versus Versao" Mensagem anterior: Thomas Hemmer: "RE: Versao concorrente = spawn of the devil?" Em resposta a: Gundersen, Richard: "RE: Ramificação estratégia - Feature vs Release" Próximo no tópico: Duncan Murdoch: "Re: Branching estratégia - Feature vs Release" Mensagens contemporâneas ordenadas: [Por Data] [Por Tópico] [Por Assunto ] [Por autor] [Por mensagens com anexos]
Este é um e-mail arquivado postado na lista de discussão Usuários do Subversion.
RE: Estratégia de Ramificação - Feature vs Release.
Data: 2006-11-08 14:15:54 CET.
Ah, eu entendo o que você quer dizer. Eu deveria experimentar as coisas antes.
Eu acho que isso é um problema com SVN ao invés de qualquer uma das estratégias,
você não acha? Ambas as abordagens sofrerão com esse recurso deficiente.
no SVN? Evidentemente, o log será mais completo se todo o desenvolvimento for.
feito em um tronco, mas ainda haverá lacunas (reconhecidamente eles serão.
De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
Enviada: quarta-feira, 8 de novembro de 2006 13:03.
Para: Gundersen, Richard.
Cc: users & # 64; subversion & # 46; tigris.
Assunto: Re: Estratégia de Ramificação - Feature vs Release.
Em 8/11/2006, às 7h34, Gundersen, Richard escreveu:
& gt; Obrigado pela resposta, mas você tem o histórico completo de um arquivo, mesmo.
& gt; se foi ramificado. Toda vez que uma alteração é feita nesse arquivo,
& gt; de qual ramificação a alteração foi feita, você recebe uma mensagem de log (desde que.
& gt; como o desenvolvedor escreve um).
& gt; Quando você finalmente mescla, você terá uma mensagem de log adicional.
& gt; dizendo algo como & quot; Mesclado de my_branch & quot ;, assim como todos os.
Eu concordo que as mensagens de log não estão perdidas, mas elas não estão anexadas ao.
arquivo no tronco, eles estão fora do ramo. Então, se você pedir um log.
de um arquivo no tronco, você não os verá. Você precisa ler o tronco.
mensagem de log para descobrir de onde a mescla veio e depois ir para lá,
e leia essas mensagens.
Isso pode eventualmente mudar se o svn obtiver melhor suporte à mesclagem, mas correto.
agora, o svn log não pode dizer a diferença entre uma fusão e outra.
mudar no tronco. Não há como o cliente automaticamente.
vincule a mensagem de registro de ramificação ao arquivo de tronco.
& gt; De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
& gt; Enviada: quarta-feira, 8 de novembro de 2006, 12:00 PM.
& gt; Assunto: Re: Estratégia de Ramificação - Feature vs Release.
& gt; Em 08/11/2006 às 5h06, Gundersen, Richard escreveu:
& gt; & gt; Nós estamos tendo um grande debate onde eu trabalho sobre se devo ou não usar o.
& gt; & gt; & quot; libertação & quot; com base em estratégia de ramificação, ou o "recurso" caminho baseado.
& gt; & gt; Eu sempre trabalhei com o último. Estas são as razões pelas quais:
& gt; & gt; 1) O tronco é sempre estável. Isso sempre imita exatamente o que está dentro
& gt; & gt; 2) Eu faço todo o trabalho novo em um ramo (seja pequeno.
& gt; & gt; mudança experimental ou uma nova versão que é essencialmente um.
& gt; & gt; de novos recursos). Isso para mim tem as seguintes vantagens adicionais.
& gt; & gt; uma. Minhas novas alterações não afetam a base de código de produção.
& gt; & gt; b. Quando o cliente que solicitou a mudança X quer que ele vá.
& gt; & gt; pode mesclá-lo no tronco (porque seu próprio ramo isolado) e.
& gt; & gt; liberar apenas essa mudança (mais o que quer que tenha sido originalmente no trunk). EU.
& gt; & gt; Cometê-lo, marcá-lo e ei pronto, o tronco ainda imita a produção.
& gt; & gt; exatamente. Com a abordagem baseada em release, com todo mundo comprometido.
& gt; & gt; mudanças diferentes para o tronco, quando um cliente quer mudar o X para ir.
& gt; & gt; ao vivo, eu tenho que dizer a ele que pode ir viver, mas eu tenho que dizer.
& gt; & gt; cliente que, porque eu tenho que liberar X, sua mudança Y também deve ir.
& gt; & gt; viva também. Essa situação pode nunca ocorrer com sistemas que possuem um.
& gt; & gt; ciclo de vida de lançamento simples, mas quando você está lidando com sistemas grandes.
& gt; & gt; com diferentes conjuntos de clientes (especialmente se eles tiverem diferentes.
& gt; & gt; requisitos legais, ou eles estão em diferentes países) eu acho que isso.
& gt; & gt; Os argumentos contra essa abordagem são frequentemente:
& gt; & gt; 1) A fusão é difícil. Eu não gosto disso.
& gt; & gt; uma. Bem, na minha experiência com o Subversion e o CVS, a fusão é.
& gt; & gt; na verdade é bem fácil. Eu poderia ter alguns conflitos para resolver todos.
& gt; & gt; e novamente, mas eles são geralmente muito fáceis de resolver, especialmente.
& gt; & gt; manter meu ramo atualizado com o tronco (que pode ter tido algum.
& gt; & gt; 2) Manter o controle de muitos ramos é difícil.
& gt; & gt; uma. Na verdade não. Se eu usar uma convenção de nomenclatura boa, um punhado de.
& gt; & gt; Filiais são fáceis o suficiente para acompanhar. Não é como se eu estivesse indo.
& gt; & gt; tem centenas de filiais para se preocupar, na realidade.
& gt; & gt; 3) Nós temos ramos de liberação para que você saiba exatamente o que está em um.
& gt; & gt; uma. Então, essa abordagem - o que quer que esteja no tronco está dentro
& gt; & gt; Produção. E, um ramo de lançamento, por definição, muda com o tempo.
& gt; & gt; é marcado como final após o qual ainda haverá um elemento de.
& gt; & gt; mesclagem envolvida para obtê-lo em sincronia com o ramo de desenvolvimento (tronco.
& gt; & gt; Eu posso ver porque as pessoas favoreciam a estratégia do ramo de lançamento,
& gt; & gt; soa muito mais simples, mas acho que os benefícios do recurso.
& gt; & gt; abordagem superam os negativos. Eu espero que muitas pessoas o façam.
& gt; & gt; discordo de mim, mas é um bom debate e eu gostaria de receber qualquer.
& gt; Um outro argumento em favor de fazer desenvolvimento no tronco e.
& gt; release from branches: Se você olhar o log de um arquivo, verá o arquivo.
& gt; histórico de alterações, não uma série de "muitas mudanças mescladas de foo.
& gt; & gt; Esta comunicação eletrônica é confidencial e exclusiva.
& gt; uso do destinatário. Pode conter privado e confidencial.
& gt; em formação. As informações, anexos e opiniões contidas em.
& gt; E-mail é apenas do autor e não representa necessariamente.
& gt; as do London Scottish Bank PLC ou de quaisquer outros membros da London.
& gt; & gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
& gt; divulgação, distribuição ou posterior cópia ou uso deste.
& gt; ou a informação contida nela ou a tomada de qualquer ação com base nela. E se.
& gt; tenha recebido esta comunicação por engano, por favor notifique o.
& gt; Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
& gt; excluir a mensagem de todos os lugares em seu computador onde está.
& gt; & gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
& gt; segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
& gt; anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
& gt; resultante de qualquer corrupção ou alteração de dados ou importação de.
& gt; qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; & gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
& gt; razões. O London Scottish Bank PLC é regulado pelo Financial.
& gt; & gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Esta comunicação eletrônica é confidencial e exclusiva.
uso do destinatário. Pode conter privado e confidencial.
em formação. As informações, anexos e opiniões contidas neste documento.
E-mail é apenas do autor e não representa necessariamente.
as do London Scottish Bank PLC ou de quaisquer outros membros da London.
& gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
divulgação, distribuição ou posterior cópia ou uso desta comunicação.
ou a informação contida nela ou a tomada de qualquer ação com base nela. Se vocês.
tenha recebido esta comunicação por engano, por favor notifique a Informação.
Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
exclua a mensagem de todos os lugares no seu computador onde ela está armazenada.
& gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
resultante de qualquer corrupção ou alteração de dados ou importação de.
qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
razões. O London Scottish Bank PLC é regulado pelos Serviços Financeiros.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Esta comunicação eletrônica é confidencial e para uso exclusivo do destinatário. Pode conter informações privadas e confidenciais. As informações, anexos e opiniões contidas neste e-mail são de seu autor e não representam necessariamente as do London Scottish Bank PLC ou de quaisquer outros membros do London Scottish Group.
Se você não for o destinatário pretendido, você está proibido de qualquer divulgação, distribuição ou cópia ou uso adicional desta comunicação ou das informações nela contidas ou de tomar qualquer medida com base nela. Se você recebeu esta comunicação por engano, por favor notifique o Gerente de Segurança da Informação na ISM & # 64; London-Scottish & # 46; com o mais rápido possível e exclua a mensagem de todos os lugares em seu computador onde ela está armazenada.
Utilizamos software de varredura de vírus, mas não podemos garantir a segurança das comunicações eletrônicas, e é recomendável que você verifique se há vírus em anexos. Não nos responsabilizamos por qualquer perda resultante de qualquer corrupção ou alteração de dados ou importação de qualquer vírus como resultado do recebimento desta comunicação eletrônica.
As respostas a este e-mail podem ser monitoradas por motivos operacionais ou comerciais. O London Scottish Bank PLC é regulado pela Financial Services Authority.
Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Recebido em Wed Nov 8 14:17:00 2006.
Esta mensagem: [Message body] Próxima mensagem: Gundersen, Richard: "RE: RE: Estratégia de ramificação - Feature vs Release" Mensagem anterior: Duncan Murdoch: "Re: Ramificação estratégia - Feature vs Release" Talvez em resposta a: Gundersen, Richard : "Estratégia de ramificação - Feature vs Release" Próximo no tópico: Gundersen, Richard: "FW: RE: Estratégia de ramificação - Feature vs Release" Talvez responda: Gundersen, Richard: "FW: RE: Estratégia de Ramificação - Feature vs Release" Mensagens contemporâneas classificado: [por data] [por segmento] [por assunto] [por autor] [por mensagens com anexos]
Este é um email arquivado postado na lista de discussão Usuários do Subversion.
Recurso de estratégia de ramificação do Subversion vs. release
Qual é a melhor estratégia de ramificação a ser usada quando você deseja fazer integração contínua?
Libertar Ramificação: desenvolver no tronco, manter um ramo para cada lançamento. Recurso ramificação: desenvolver cada recurso em um ramo separado, apenas mesclar uma vez estável.
Faz sentido usar essas duas estratégias juntas? Como em, você ramifica para cada lançamento, mas você também ramifica para grandes recursos? Uma dessas estratégias combina melhor com a integração contínua? O uso de integração contínua faria sentido ao usar um tronco instável?
11 respostas.
A resposta depende do tamanho da equipe e da qualidade do controle de origem e da capacidade de mesclar conjuntos de mudanças complexos corretamente. Por exemplo, no controle de fonte de ramificação completa como CVS ou SVN, a fusão pode ser difícil e você pode estar melhor com o primeiro modelo, enquanto se estiver usando um sistema mais complexo como o IBM ClearCase e com um tamanho maior de equipe, modelo ou uma combinação dos dois.
Eu pessoalmente separaria o modelo de ramificação de feições, onde cada característica principal é desenvolvida em uma ramificação separada, com sub-ramificações de tarefas para cada modificação feita pelo desenvolvedor individual. À medida que os recursos se estabilizam, eles são mesclados ao tronco, que você mantém razoavelmente estável e passando em todos os testes de regressão o tempo todo. À medida que você se aproxima do final de seu ciclo de lançamento e todos os ramos de recursos se mesclam, você estabiliza e ramifica uma ramificação do sistema de lançamento na qual você faz apenas correções de bugs de estabilidade e backports necessários, enquanto o tronco é usado para desenvolvimento da próxima versão e você novamente ramificar para novos ramos de recurso. E assim por diante.
Desta forma, o trunk contém sempre o código mais recente, mas você consegue mantê-lo razoavelmente estável, criando rótulos estáveis (tags) em grandes mudanças e mesclagens de recursos, os ramos de recursos são desenvolvimento rápido com integração contínua e sub-ramificações de tarefas individuais atualizado a partir do ramo de recursos para manter todos trabalhando no mesmo recurso em sincronia, sem afetar outras equipes que trabalham em diferentes recursos.
Ao mesmo tempo, você tem através do histórico um conjunto de releases, onde você pode fornecer backports, suporte e correções de bugs para seus clientes que, por qualquer motivo, permanecem em versões anteriores de seu produto ou até mesmo na última versão lançada. Tal como acontece com o tronco, você não configura a integração contínua nos ramos de lançamento, eles são cuidadosamente integrados ao passarem por todos os testes de regressão e outro controle de qualidade do release.
Se, por algum motivo, dois recursos forem co-dependentes e precisarem de alterações feitos um pelo outro, você poderá considerar desenvolver ambos no mesmo ramo de recursos ou exigir que os recursos mescle regularmente partes estáveis do código no tronco e, em seguida, atualize as alterações tronco para troca de código entre os ramos do tronco. Ou, se você precisar isolar esses dois recursos de outros, poderá criar uma ramificação comum na qual ramificará essas ramificações de recurso e poderá usá-la para trocar códigos entre os recursos.
O modelo acima não faz muito sentido com equipes com menos de 50 desenvolvedores e sistema de controle de código-fonte sem ramificações esparsas e capacidade de mesclagem adequada como CVS ou SVN, o que tornaria todo esse modelo um pesadelo para configurar, gerenciar e integrar.
Eu acho o tópico realmente interessante, já que confio fortemente em ramificações no meu trabalho diário.
Lembro-me de Mark Shuttleworth propondo um modelo sobre manter o ramo principal intocado, indo além do IC convencional. Eu postei sobre isso aqui. Desde que eu estou familiarizado com o controle de cruzeiro, eu também bloguei sobre ramos de tarefas e CI aqui. É um tutorial passo a passo explicando como fazer isso com o Plastic SCM. Finalmente, encontrei alguns dos tópicos sobre CI (e potencialmente falando sobre ramificação) no livro de Duvall sobre CI muito interessante também.
Espero que você ache os links interessantes.
Eu pessoalmente acho muito mais limpo ter um tronco estável e fazer ramificações. Dessa forma, os testadores e afins ficam em uma única "versão" e atualizam a partir do tronco para testar qualquer recurso que seja um código completo.
Além disso, se vários desenvolvedores estiverem trabalhando em recursos diferentes, todos poderão ter suas próprias ramificações separadas e, em seguida, mesclar ao tronco quando terminarem e enviar um recurso a ser testado sem que o testador tenha que alternar para várias ramificações para testar recursos diferentes.
Como um bônus adicional, existe algum nível de teste de integração que vem automaticamente.
Eu acho que qualquer estratégia pode ser usada com desenvolvimento contínuo, desde que você se lembre de um dos princípios-chave que cada desenvolvedor compromete com o trunk / mainline todos os dias.
Eu tenho feito algumas leituras deste livro sobre CI e os autores sugerem que ramificar por lançamento é a estratégia de ramificação preferida. Eu tenho que concordar. A ramificação por recurso não faz sentido para mim ao usar o IC.
Vou tentar explicar porque estou pensando assim. Diga que três desenvolvedores pegam uma filial para trabalhar em um recurso. Cada recurso levará vários dias ou semanas para ser concluído. Para garantir que a equipe esteja continuamente integrando, eles devem se comprometer com a agência principal pelo menos uma vez por dia. Assim que começam a fazer isso, perdem o benefício de criar um branch de recursos. Suas mudanças não estão mais separadas de todas as outras mudanças do desenvolvedor. Sendo esse o caso, por que se preocupar em criar branches em primeiro lugar?
Usar a ramificação por release requer muito menos mesclagem entre filiais (sempre uma coisa boa), garante que todas as alterações sejam integradas o mais rápido possível e (se feito corretamente) garante que sua base de código esteja sempre pronta para ser liberada. O lado negativo da ramificação por release é que você precisa ser consideravelmente mais cuidadoso com as mudanças. Por exemplo. A refatoração grande deve ser feita de forma incremental e, se você já integrou um novo recurso que não deseja na próxima versão, ele deve ser oculto usando algum tipo de mecanismo de alternância de recursos.
Há mais de uma opinião sobre este assunto. Aqui está uma postagem no blog que é pro feature branching with CI.
As ramificações de lançamento são muito úteis e até mesmo absolutamente necessárias, se você precisar manter várias versões do seu aplicativo.
As ramificações de recursos também são muito convenientes, especialmente se um desenvolvedor precisar trabalhar em uma grande mudança, enquanto outras ainda lançam novas versões.
Então, para mim, usar os dois mecanismos é uma estratégia muito boa.
Link interessante do livro do SVN.
Eu recentemente cheguei a gostar deste modelo ao usar o git. Embora sua pergunta seja marcada como "svn", talvez você ainda possa usá-la.
A Integração Contínua pode, até certo ponto, acontecer na ramificação "desenvolver" (ou como você a chama) nesse modelo, embora ter ramificações longas de recursos para versões futuras não torne isso tão rígido a ponto de considerar cada mudança acontecendo em algum lugar. A questão permanece, se você realmente quer isso. Martin Fowler faz.
A integração contínua não deve ser nenhum tipo de fator na determinação de sua estratégia de ramificação. Sua abordagem de ramificação deve ser selecionada com base em sua equipe, no sistema em desenvolvimento e nas ferramentas disponíveis para você.
Tendo dito isto .
não há razão para que o CI não possa ser usado em ambas as abordagens que você descreve que essas abordagens funcionam muito bem em combinação, nenhum dos dois funciona "melhor" do que o outro CI faz todo o sentido com um tronco instável.
Tudo isso foi respondido na quarta pergunta na página em que você tirou os diagramas de: blogs. collab / subversion / 2007/11 / branching-strat /
Contanto que você entenda os princípios, você sempre pode reinventar as melhores práticas. Se você não entende princípios, as melhores práticas levarão você tão longe antes de desmoronar devido a algum requisito externo conflitante.
Leia o link. Depois de obter o básico, leia o seguinte artigo do venerável Henrik Kniberg. Isso ajudará você a relacionar o Modelo Principal com a integração contínua.
Quando começamos nossa equipe, herdamos uma estratégia baseada no release do fornecedor que originalmente desenvolveu o sistema que estávamos prestes a assumir. Funcionou até o momento em que nossos clientes solicitaram que vários recursos desenvolvidos não fossem incluídos em uma versão (f. y.i.
250k linhas de código,
2500 arquivos, Scrum com XP SDLC).
Então começamos a olhar para os ramos baseados em funcionalidades. Isso também funcionou por um tempo - como dois meses até o momento em que percebemos que nosso processo de teste de regressão levaria mais de duas semanas, o que, combinado com a incerteza do que seria lançado, criaria um enorme inconveniente.
A última "unha no caixão" das estratégias de CS puro veio quando decidimos que deveríamos ter 1. tronco estável e 2. A produção deveria conter BINÁRIOS testados de ST, UAT e Regressão (não apenas fonte - pense em CC.)
Isso nos levou a elaborar uma estratégia que é um híbrido entre as estratégias de SC baseadas em recursos e em releases.
Então nós temos um baú. Em cada sprint, nós ramificamos o ramo de sprint (para o pessoal não ágil - um sprint é apenas um esforço de desenvolvimento com saída variável baseado na complexidade). A partir do ramo de sprint, criamos os ramos de recursos e o desenvolvimento paralelo é iniciado neles. Depois que os recursos são concluídos e testados pelo sistema, e recebemos a intenção de implantá-los, eles são mesclados à ramificação do sprint - alguns podem flutuar em vários sprints, geralmente os mais complexos. Quando o sprint estiver próximo do final e os recursos estiverem completos. nós "renomeamos" o ramo de sprint para "regressão" (isso permite que o CruiseControl o pegue sem qualquer reconfiguração) e, em seguida, o teste de regressão / integração começa no EAR construído em cc. Quando tudo isso é feito, entra em produção.
Em suma, as ramificações baseadas em recursos são usadas para desenvolver, testar o sistema e funcionalidade UAT. O ramo de sprint (realmente o ramo de lançamento) é usado para mesclar seletivamente os recursos sob demanda e teste de integração.
Agora, aqui está uma pergunta para a comunidade - obviamente, estamos tendo problemas para realizar a integração contínua devido ao fato de que o desenvolvimento acontece em muitos ramos e na sobrecarga de reconfiguração do CruiseControl. Alguém pode sugerir e aconselhar?
Do jeito que eu vejo, você quer ter um conjunto limitado de ramificações onde você possa se concentrar. Como você deseja testes, métricas de qualidade de código e muitas coisas interessantes para executar com as compilações, ter muitos relatórios provavelmente fará você perder informações.
Quando e o que ramificar, geralmente depende do tamanho da equipe e do tamanho dos recursos que estão sendo desenvolvidos. Eu não acho que haja uma regra de ouro. Certifique-se de usar uma estratégia na qual você possa obter feedback com antecedência / frequência, e isso inclui ter a qualidade envolvida desde o início dos recursos. O bit de qualidade significa que, à medida que você está automatizando à medida que a equipe se desenvolve, se você se ramificar para um grande conjunto de recursos que uma equipe está construindo, você também precisa envolver a qualidade da equipe.
ps Onde você conseguiu essas referências de abordagem? - não acha que esses gráficos representam todas as opções.
Atualização 1: Expandindo porque eu disse que não é uma regra de ouro. Basicamente, para equipes relativamente pequenas, achei melhor usar uma abordagem que é uma mistura. As ramificações de recursos são criadas se for algo longo e parte da equipe continuará adicionando recursos menores.
Eu acho que as ferramentas que você usa são um grande fator aqui.
Se você estiver usando subversão, continue com a opção 1 e libere das ramificações. Se você estiver usando o GIT, a opção 2 funcionará bem para você.
Recurso ramificando seu caminho para a grandeza.
Ou tarefa ramificando seu caminho até lá. Ou libere ramificações. Você escolhe.
Quase todos os sistemas de controle de versão atualmente suportam ramificações - linhas independentes de trabalho que derivam de uma base de código central. Dependendo do sistema de controle de versão, o ramo principal pode ser chamado de mestre, principal, padrão ou tronco. Os desenvolvedores podem criar suas próprias ramificações a partir da linha de código principal e trabalhar de forma independente ao lado dela.
Por que se preocupar com ramificação?
A ramificação permite que equipes de desenvolvedores colaborem facilmente dentro de uma base de código central. Quando um desenvolvedor cria uma ramificação, o sistema de controle de versão cria uma cópia da base de código naquele momento. As alterações na agência não afetam outros desenvolvedores da equipe. Isso é uma coisa boa, obviamente, porque os recursos em desenvolvimento podem criar instabilidade, o que seria altamente prejudicial se todo o trabalho estivesse acontecendo na linha de código principal. Mas as filiais não precisam viver em confinamento solitário. Os desenvolvedores podem facilmente remover as alterações de outros desenvolvedores para colaborar em recursos e garantir que sua ramificação privada não seja muito distante do mestre.
Os branches não são bons apenas para o trabalho de recursos. Filiais podem isolar a equipe de importantes mudanças arquiteturais, como a atualização de estruturas, bibliotecas comuns etc.
Três estratégias de ramificação para equipes ágeis.
Os modelos de ramificação geralmente diferem entre as equipes e são assunto de muito debate na comunidade de software. Um grande tema é quanto trabalho deve permanecer em um branch antes de ser mesclado de volta ao master.
Liberar ramificação.
Liberar ramificação refere-se à ideia de que uma liberação está contida inteiramente dentro de uma ramificação. Isso significa que, no final do ciclo de desenvolvimento, o gerente de lançamento criará uma ramificação do mestre (por exemplo, & ldquo; 1.1 filial de desenvolvimento & rdquo;). Todas as alterações para a versão 1.1 precisam ser aplicadas duas vezes: uma vez para a ramificação 1.1 e, em seguida, para a linha de código principal. Trabalhar com duas filiais é um trabalho extra para a equipe e é fácil esquecer de se mesclar a ambas as filiais. As ramificações de versão podem ser difíceis e difíceis de gerenciar, já que muitas pessoas estão trabalhando no mesmo ramo. Todos nós sentimos a dor de ter que mesclar muitas mudanças diferentes em um único ramo. Se você deve fazer um branch de release, crie o branch o mais próximo possível do release atual.
O lançamento de ramificações é uma parte importante do suporte a softwares com versão no mercado. Um único produto pode ter vários ramos de liberação (por exemplo, 1.1, 1.2, 2.0) para suportar o desenvolvimento de sustentação. Lembre-se de que as alterações nas versões anteriores (por exemplo, 1.1) podem precisar ser mescladas em filiais de liberação posteriores (por exemplo, 1.2, 2.0). Confira nosso webinar abaixo para saber mais sobre o gerenciamento de filiais de lançamento com o Git.
Ramificação de recursos.
Os ramos de funcionalidades são frequentemente associados a flags de funcionalidades & ndash; & quot; alterna & quot; que habilitam ou desabilitam um recurso dentro do produto. Isso facilita a implantação do código no mestre e no controle quando o recurso é ativado, facilitando a implantação inicial do código antes que o recurso seja exposto aos usuários finais.
Outro benefício de sinalizadores de recursos é que o código pode permanecer dentro da compilação, mas inativo enquanto está em desenvolvimento. Se algo der errado quando o recurso estiver habilitado, um administrador do sistema poderá reverter o sinalizador de recurso e voltar a um bom estado conhecido, em vez de precisar implantar uma nova compilação.
Tarefa Ramificação.
Na Atlassian, nos concentramos em um fluxo de trabalho de ramificação por tarefa. Cada organização tem uma maneira natural de dividir o trabalho em tarefas individuais dentro de um rastreador de problemas, como o Jira Software. Questões, em seguida, torna-se ponto de contato central da equipe para esse trabalho. A ramificação de tarefas, também conhecida como ramificação de problemas, conecta diretamente esses problemas ao código-fonte. Cada problema é implementado em sua própria ramificação com a chave de problema incluída no nome da ramificação. É fácil ver qual código implementa o problema: basta procurar a chave de problema no nome da ramificação. Com esse nível de transparência, é mais fácil aplicar alterações específicas na ramificação de lançamento legado em execução ou mestre.
Como os centros ágeis em torno de histórias de usuários, os ramos de tarefas combinam bem com o desenvolvimento ágil. Cada história de usuário (ou correção de bug) reside em sua própria ramificação, facilitando a visualização de quais problemas estão em andamento e quais estão prontos para serem lançados. Para um mergulho profundo na ramificação de tarefas (às vezes chamada de ramificação de problema ou branch-por-issue), pegue um pouco de pipoca e confira a gravação do webinar abaixo - um dos mais populares de todos os tempos.
Agora encontre o gêmeo maligno da ramificação: a fusão.
Todos sofremos a dor de tentar integrar vários ramos em uma solução sensata. Tradicionalmente, sistemas centralizados de controle de versão, como o Subversion, fizeram da fusão uma operação muito dolorosa. Mas os sistemas de controle de versão mais recentes, como o Git e o Mercurial, adotam uma abordagem diferente para rastrear versões de arquivos que residem em diferentes filiais.
As ramificações tendem a ter vida curta, facilitando a mesclagem e a flexibilidade na base de código. Entre a capacidade de mesclar freqüências e automaticamente ramificações como parte da integração contínua (CI) e o fato de que as ramificações de vida curta simplesmente contêm menos alterações, & quot; mesclar o inferno & quot; Torna-se uma coisa do passado para as equipes que usam Git e Mercurial.
É isso que torna a ramificação de tarefas tão incrível!
Valide, valide, valide.
Um sistema de controle de versão só pode ir tão longe ao afetar o resultado de uma mesclagem. Testes automatizados e integração contínua também são críticos. A maioria dos servidores de CI pode colocar automaticamente novos ramos em teste, reduzindo drasticamente o número de "surpresas" na junção final do upstream e ajudando a manter a linha de código principal estável.
O Agile teve um impacto enorme em mim tanto profissional quanto pessoalmente, pois aprendi que as melhores experiências são ágeis, tanto no código quanto na vida. Você muitas vezes me encontra na intersecção entre tecnologia, fotografia e motociclismo. Encontre-me no Twitter! @danradigan.
Inscreva-se para mais artigos.
Obrigado por inscrever-se!
Como fazer scrum com o software Jira.
Um guia passo-a-passo sobre como conduzir um projeto scrum, priorizar e organizar seu backlog em sprints, executar as cerimônias Scrum e muito mais, tudo dentro do Jira Software.
Git ramificando para equipes ágeis.
Mudar para o Git abre um novo nível de agilidade para as equipes de software. Veja como criar esquemas de ramificação para enviar produtos SaaS e instalados.
Como estamos desenvolvendo em um sistema implantado, estamos tentando usar melhor as ramificações - Até recentemente, quase tudo era verificado no trunk, implantado para testar / testar e depois para produção. Isso significa que temos que ter muito cuidado durante o período de "Teste", e ainda assim, ocasionalmente, recebemos alterações indesejadas enviadas ao servidor com poucos testes.
Meu pensamento é que a melhor maneira seria os patches "secundários" irem direto ao tronco, os principais recursos se transformam em ramificações de recursos que são reintegrados no tronco quando completos e em uma ramificação "Produção" que sempre corresponde ao estado do servidor em que podemos mesclar implantação.
O principal benefício oferecido aqui é que você pode escolher quais mudanças serão lançadas na produção - se você quiser, pode pegar um único check-in ou filial e enviá-lo para a produção sem envolver todos os outros ramos.
Por outro lado, parece ser melhor ter filiais. Integre com o tronco frequentemente - faça mudanças para que elas não se acumulem e façam uma fusão desagradável.
Portanto, esses dois padrões podem levar ao caso em que você deseja mesclar uma ramificação com a Produção para trazer um recurso importante, mas essa ramificação já "inseriu" as alterações do tronco que você não deseja enviar.
O SVN pode lidar com isso? Existem práticas realmente boas que funcionam para grupos que desenvolvem código que é implantado a cada duas semanas?
Eu acho que tudo o que você descreve é possível com (uma versão atual como 1.7 ou 1.8 do Subversion). Aqui estão os passos a seguir:
Descreva suas estratégias de ramificação (e mesclagem). Você não pode misturar facilmente todos eles, e é difícil para os desenvolvedores saberem qual estratégia é usada onde, então a documentação e a comunicação estão aqui. Veja os seguintes recursos: Melhor estratégia de ramificação ao fazer integração contínua? Padrões comuns de ramificação Você usará o seguinte: Liberar ramificação para a liberação de produção, os patches são desenvolvidos diretamente lá. Para cada patch, você deve decidir se o patch deve estar disponível (no mesmo formulário) na próxima versão. Use o tronco para o desenvolvimento principal. Tudo o que você tem certeza de que estará no próximo lançamento deve ser desenvolvido no porta-malas. Não se fundir do tronco para (liberar) filial. Jamais!! Use as ramificações de recursos somente se você não tiver certeza se um recurso chegará à próxima versão. As ramificações de funcionalidades são (no Subversion) muito mais difíceis do que, e. no Git, então deve haver uma razão para usá-los. Mesclar todas as alterações do tronco para o ramo de recurso regularmente e apenas reintegrar no final, quando o recurso estiver integrado no tronco (para chegar à próxima versão). Encontre o ponto certo no tempo para fazer a ramificação e a mesclagem: Ramificação: Quando é necessário um branch de release estável (para integração com a próxima release), e quando o desenvolvimento pode começar para a seguinte release (então no trunk novamente)? Mesclagem: quando é o melhor momento para mesclar as alterações: Imediato, quando a alteração é recente; regularmente de vez em quando; (esperemos que não) apenas uma vez no final.
Suas filiais serão desenvolvidas ao longo do tempo assim:
Você começa com o tronco (e somente o tronco) para o lançamento 1.0, seu primeiro lançamento. Você ramifica o tronco, quando deseja fazer o teste de integração para o release 1.0 e inicia o desenvolvimento para o release 1.1 (no tronco). Você entrega o release 1.0 e fornece posteriormente patches diretamente do branch. Você ramifica o tronco, quando deseja fazer o teste de integração para o release 1.1 e inicia o desenvolvimento para o release 1.2 (ou 2.0) no tronco. . e assim por diante .
Ramificação e fusão do SVN Red Book explica tudo o que você precisa tecnicamente, mas não é tão claro como fazê-lo em diferentes contextos de negócios (minha opinião pessoal). Eu não encontrei um recurso que explica todas as opções e drivers por trás deles com detalhes suficientes.
Re: estratégia de ramificação - Feature vs Release.
Data: 2006-11-08 14:01:13 CET.
Esse é um ótimo tópico, parabéns por começar.
Na minha empresa, estamos usando svn e uma mistura de release e feature.
ramo. Estou tentando fazer com que funcione em uma estratégia de ramificação de lançamento.
Mas. temos 3/4 grandes aplicações. Os lançamentos são feitos por.
projeto, que adiciona um pouco de complexidade, como às vezes o mesmo.
aplicação é liberada em um prazo de 2/3 semanas, que então o.
mudanças precisam ser feitas em ambos os ramos de lançamentos e tronco, sim, a.
bagunça. :) Outro fator de complexidade é que armazenamos nossos JSP's em um.
repositório diferente, que então precisa sempre ser ramificado juntos.
Se não bastasse, todo o nosso código está espalhado na mesma raiz. Nós temos.
módulos refinados que são usados nas três aplicações, então o.
ramos são todos tirados da raiz.
Espero que tenhamos mais aplicativos separados, que incluam os JPSs.
e arquivos de configuração (os arquivos são armazenados em um terceiro repo :)) e.
seguindo uma abordagem de ramificação de lançamento consistente.
Minha pergunta, qual é a melhor abordagem de release / ramificação para esse tipo.
de lançamentos, que são feitos por projeto e não por aplicativo.
Em 08/11/06, Gundersen, Richard & lt; Richard. Gundersen & # 64; london-scottish & # 46; com & gt; escrevi:
& gt; Obrigado pela resposta, mas você tem o histórico completo de um arquivo, mesmo.
& gt; se foi ramificado. Toda vez que uma alteração é feita para esse arquivo, independentemente disso.
& gt; de qual ramificação a alteração foi feita, você recebe uma mensagem de log (desde que.
& gt; como o desenvolvedor escreve um).
& gt; Quando você finalmente mescla, você terá uma mensagem de log adicional.
& gt; dizendo algo como & quot; Mesclado de my_branch & quot ;, assim como todos os.
& gt; De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
& gt; Enviada: quarta-feira, 8 de novembro de 2006, 12:00 PM.
& gt; Assunto: Re: Estratégia de Ramificação - Feature vs Release.
& gt; Em 08/11/2006 às 5h06, Gundersen, Richard escreveu:
& gt; & gt; Nós estamos tendo um grande debate onde eu trabalho sobre se devo ou não usar o.
& gt; & gt; & quot; libertação & quot; com base em estratégia de ramificação, ou o "recurso" caminho baseado.
& gt; & gt; Eu sempre trabalhei com o último. Estas são as razões pelas quais:
& gt; & gt; 1) O tronco é sempre estável. Isso sempre imita exatamente o que está dentro
& gt; & gt; 2) Eu faço todo o trabalho novo em um ramo (seja pequeno.
& gt; & gt; mudança experimental ou uma nova versão que é essencialmente uma coleção.
& gt; & gt; de novos recursos). Isso para mim tem as seguintes vantagens adicionais.
& gt; & gt; uma. Minhas novas alterações não afetam a base de código de produção.
& gt; & gt; b. Quando o cliente que solicitou a alteração X deseja que ele seja ativado,
& gt; & gt; pode mesclá-lo no tronco (porque seu próprio ramo isolado) e.
& gt; & gt; liberar apenas essa mudança (mais o que quer que tenha sido originalmente no trunk). EU.
& gt; & gt; Cometê-lo, marcá-lo e ei pronto, o tronco ainda imita a produção.
& gt; & gt; exatamente. Com a abordagem baseada em release, com todo mundo comprometido.
& gt; & gt; mudanças diferentes para o tronco, quando um cliente quer mudar X para ir.
& gt; & gt; ao vivo, eu tenho que dizer a ele que pode ir viver, mas eu tenho que dizer.
& gt; & gt; cliente que, porque eu tenho que liberar X, sua mudança Y também deve ir.
& gt; & gt; viva também. Essa situação pode nunca ocorrer com sistemas que possuem um.
& gt; & gt; ciclo de vida de lançamento simples, mas quando você está lidando com sistemas grandes.
& gt; & gt; com diferentes conjuntos de clientes (especialmente se eles tiverem diferentes.
& gt; & gt; requisitos legais, ou eles estão em diferentes países) eu acho que isso.
& gt; & gt; Os argumentos contra essa abordagem são frequentemente:
& gt; & gt; 1) A fusão é difícil. Eu não gosto disso.
& gt; & gt; uma. Bem, na minha experiência com o Subversion e o CVS, a fusão é.
& gt; & gt; na verdade é bem fácil. Eu poderia ter alguns conflitos para resolver a cada momento.
& gt; & gt; e novamente, mas eles são geralmente muito fáceis de resolver, especialmente se.
& gt; & gt; manter meu ramo atualizado com o tronco (que pode ter tido algum.
& gt; & gt; 2) Manter o controle de muitos ramos é difícil.
& gt; & gt; uma. Na verdade não. Se eu usar uma convenção de nomenclatura boa, um punhado de.
& gt; & gt; Filiais são fáceis o suficiente para acompanhar. Não é como se eu fosse.
& gt; & gt; tem centenas de filiais para se preocupar, na realidade.
& gt; & gt; 3) Nós temos ramos de liberação para que você saiba exatamente o que está em um.
& gt; & gt; uma. Então, essa abordagem - o que quer que esteja no tronco está dentro
& gt; & gt; Produção. E, um ramo de lançamento, por definição, muda com o tempo.
& gt; & gt; é marcado como final após o qual ainda haverá um elemento de.
& gt; & gt; mesclagem envolvida para obtê-lo em sincronia com o ramo de desenvolvimento (tronco.
& gt; & gt; Eu posso ver porque as pessoas favoreciam a estratégia do ramo de lançamento, porque.
& gt; & gt; soa muito mais simples, mas acho que os benefícios do recurso.
& gt; & gt; abordagem superam os negativos. Eu espero que muitas pessoas o façam.
& gt; & gt; discordo de mim, mas é um bom debate e eu gostaria de receber qualquer comentário.
& gt; Um outro argumento em favor de fazer desenvolvimento no tronco e.
& gt; release from branches: Se você olhar o log de um arquivo, verá o arquivo.
& gt; histórico de alterações, não uma série de "muitas mudanças mescladas de foo.
& gt; & gt; Esta comunicação eletrônica é confidencial e exclusiva.
& gt; uso do destinatário. Pode conter privado e confidencial.
& gt; em formação. As informações, anexos e opiniões contidas neste documento.
& gt; E-mail é apenas do autor e não representa necessariamente.
& gt; os do London Scottish Bank PLC ou de quaisquer outros membros do London.
& gt; & gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
& gt; divulgação, distribuição ou posterior cópia ou uso desta comunicação.
& gt; ou a informação contida nela ou a tomada de qualquer ação com base nela. Se vocês.
& gt; tenha recebido esta comunicação por engano, por favor notifique a Informação.
& gt; Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
& gt; exclua a mensagem de todos os lugares no seu computador onde ela está armazenada.
& gt; & gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
& gt; segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
& gt; anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
& gt; resultante de qualquer corrupção ou alteração de dados ou importação de.
& gt; qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; & gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
& gt; razões. O London Scottish Bank PLC é regulado pelos Serviços Financeiros.
& gt; & gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Esta comunicação eletrônica é confidencial e para uso exclusivo do destinatário. Pode conter informações privadas e confidenciais. As informações, anexos e opiniões contidas neste e-mail são de seu autor e não representam necessariamente as do London Scottish Bank PLC ou de quaisquer outros membros do London Scottish Group.
& gt; Se você não for o destinatário pretendido, você está proibido de qualquer divulgação, distribuição ou cópia ou uso adicional desta comunicação ou das informações nela contidas ou de tomar qualquer medida com base nela. Se você recebeu esta comunicação por engano, por favor notifique o Gerente de Segurança da Informação na ISM & # 64; London-Scottish & # 46; com o mais rápido possível e exclua a mensagem de todos os lugares em seu computador onde ela está armazenada.
& gt; Utilizamos software de varredura de vírus, mas não podemos garantir a segurança das comunicações eletrônicas, e é recomendável que você verifique se há vírus em anexos. Não nos responsabilizamos por qualquer perda resultante de qualquer corrupção ou alteração de dados ou importação de qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; As respostas a este e-mail podem ser monitoradas por motivos operacionais ou comerciais. O London Scottish Bank PLC é regulado pela Financial Services Authority.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
& gt; Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Recebido em Wed Nov 8 14:02:07 2006.
Esta mensagem: [Corpo da mensagem] Próxima mensagem: Duncan Murdoch: "Re: Estratégia de Ramificação - Versao versus Versao" Mensagem anterior: Thomas Hemmer: "RE: Versao concorrente = spawn of the devil?" Em resposta a: Gundersen, Richard: "RE: Ramificação estratégia - Feature vs Release" Próximo no tópico: Duncan Murdoch: "Re: Branching estratégia - Feature vs Release" Mensagens contemporâneas ordenadas: [Por Data] [Por Tópico] [Por Assunto ] [Por autor] [Por mensagens com anexos]
Este é um e-mail arquivado postado na lista de discussão Usuários do Subversion.
RE: Estratégia de Ramificação - Feature vs Release.
Data: 2006-11-08 14:15:54 CET.
Ah, eu entendo o que você quer dizer. Eu deveria experimentar as coisas antes.
Eu acho que isso é um problema com SVN ao invés de qualquer uma das estratégias,
você não acha? Ambas as abordagens sofrerão com esse recurso deficiente.
no SVN? Evidentemente, o log será mais completo se todo o desenvolvimento for.
feito em um tronco, mas ainda haverá lacunas (reconhecidamente eles serão.
De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
Enviada: quarta-feira, 8 de novembro de 2006 13:03.
Para: Gundersen, Richard.
Cc: users & # 64; subversion & # 46; tigris.
Assunto: Re: Estratégia de Ramificação - Feature vs Release.
Em 8/11/2006, às 7h34, Gundersen, Richard escreveu:
& gt; Obrigado pela resposta, mas você tem o histórico completo de um arquivo, mesmo.
& gt; se foi ramificado. Toda vez que uma alteração é feita nesse arquivo,
& gt; de qual ramificação a alteração foi feita, você recebe uma mensagem de log (desde que.
& gt; como o desenvolvedor escreve um).
& gt; Quando você finalmente mescla, você terá uma mensagem de log adicional.
& gt; dizendo algo como & quot; Mesclado de my_branch & quot ;, assim como todos os.
Eu concordo que as mensagens de log não estão perdidas, mas elas não estão anexadas ao.
arquivo no tronco, eles estão fora do ramo. Então, se você pedir um log.
de um arquivo no tronco, você não os verá. Você precisa ler o tronco.
mensagem de log para descobrir de onde a mescla veio e depois ir para lá,
e leia essas mensagens.
Isso pode eventualmente mudar se o svn obtiver melhor suporte à mesclagem, mas correto.
agora, o svn log não pode dizer a diferença entre uma fusão e outra.
mudar no tronco. Não há como o cliente automaticamente.
vincule a mensagem de registro de ramificação ao arquivo de tronco.
& gt; De: Duncan Murdoch [mailto: murdoch & # 64; stats & # 46; uwo. ca]
& gt; Enviada: quarta-feira, 8 de novembro de 2006, 12:00 PM.
& gt; Assunto: Re: Estratégia de Ramificação - Feature vs Release.
& gt; Em 08/11/2006 às 5h06, Gundersen, Richard escreveu:
& gt; & gt; Nós estamos tendo um grande debate onde eu trabalho sobre se devo ou não usar o.
& gt; & gt; & quot; libertação & quot; com base em estratégia de ramificação, ou o "recurso" caminho baseado.
& gt; & gt; Eu sempre trabalhei com o último. Estas são as razões pelas quais:
& gt; & gt; 1) O tronco é sempre estável. Isso sempre imita exatamente o que está dentro
& gt; & gt; 2) Eu faço todo o trabalho novo em um ramo (seja pequeno.
& gt; & gt; mudança experimental ou uma nova versão que é essencialmente um.
& gt; & gt; de novos recursos). Isso para mim tem as seguintes vantagens adicionais.
& gt; & gt; uma. Minhas novas alterações não afetam a base de código de produção.
& gt; & gt; b. Quando o cliente que solicitou a mudança X quer que ele vá.
& gt; & gt; pode mesclá-lo no tronco (porque seu próprio ramo isolado) e.
& gt; & gt; liberar apenas essa mudança (mais o que quer que tenha sido originalmente no trunk). EU.
& gt; & gt; Cometê-lo, marcá-lo e ei pronto, o tronco ainda imita a produção.
& gt; & gt; exatamente. Com a abordagem baseada em release, com todo mundo comprometido.
& gt; & gt; mudanças diferentes para o tronco, quando um cliente quer mudar o X para ir.
& gt; & gt; ao vivo, eu tenho que dizer a ele que pode ir viver, mas eu tenho que dizer.
& gt; & gt; cliente que, porque eu tenho que liberar X, sua mudança Y também deve ir.
& gt; & gt; viva também. Essa situação pode nunca ocorrer com sistemas que possuem um.
& gt; & gt; ciclo de vida de lançamento simples, mas quando você está lidando com sistemas grandes.
& gt; & gt; com diferentes conjuntos de clientes (especialmente se eles tiverem diferentes.
& gt; & gt; requisitos legais, ou eles estão em diferentes países) eu acho que isso.
& gt; & gt; Os argumentos contra essa abordagem são frequentemente:
& gt; & gt; 1) A fusão é difícil. Eu não gosto disso.
& gt; & gt; uma. Bem, na minha experiência com o Subversion e o CVS, a fusão é.
& gt; & gt; na verdade é bem fácil. Eu poderia ter alguns conflitos para resolver todos.
& gt; & gt; e novamente, mas eles são geralmente muito fáceis de resolver, especialmente.
& gt; & gt; manter meu ramo atualizado com o tronco (que pode ter tido algum.
& gt; & gt; 2) Manter o controle de muitos ramos é difícil.
& gt; & gt; uma. Na verdade não. Se eu usar uma convenção de nomenclatura boa, um punhado de.
& gt; & gt; Filiais são fáceis o suficiente para acompanhar. Não é como se eu estivesse indo.
& gt; & gt; tem centenas de filiais para se preocupar, na realidade.
& gt; & gt; 3) Nós temos ramos de liberação para que você saiba exatamente o que está em um.
& gt; & gt; uma. Então, essa abordagem - o que quer que esteja no tronco está dentro
& gt; & gt; Produção. E, um ramo de lançamento, por definição, muda com o tempo.
& gt; & gt; é marcado como final após o qual ainda haverá um elemento de.
& gt; & gt; mesclagem envolvida para obtê-lo em sincronia com o ramo de desenvolvimento (tronco.
& gt; & gt; Eu posso ver porque as pessoas favoreciam a estratégia do ramo de lançamento,
& gt; & gt; soa muito mais simples, mas acho que os benefícios do recurso.
& gt; & gt; abordagem superam os negativos. Eu espero que muitas pessoas o façam.
& gt; & gt; discordo de mim, mas é um bom debate e eu gostaria de receber qualquer.
& gt; Um outro argumento em favor de fazer desenvolvimento no tronco e.
& gt; release from branches: Se você olhar o log de um arquivo, verá o arquivo.
& gt; histórico de alterações, não uma série de "muitas mudanças mescladas de foo.
& gt; & gt; Esta comunicação eletrônica é confidencial e exclusiva.
& gt; uso do destinatário. Pode conter privado e confidencial.
& gt; em formação. As informações, anexos e opiniões contidas em.
& gt; E-mail é apenas do autor e não representa necessariamente.
& gt; as do London Scottish Bank PLC ou de quaisquer outros membros da London.
& gt; & gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
& gt; divulgação, distribuição ou posterior cópia ou uso deste.
& gt; ou a informação contida nela ou a tomada de qualquer ação com base nela. E se.
& gt; tenha recebido esta comunicação por engano, por favor notifique o.
& gt; Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
& gt; excluir a mensagem de todos os lugares em seu computador onde está.
& gt; & gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
& gt; segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
& gt; anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
& gt; resultante de qualquer corrupção ou alteração de dados ou importação de.
& gt; qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; & gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
& gt; razões. O London Scottish Bank PLC é regulado pelo Financial.
& gt; & gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
& gt; Esta comunicação eletrônica é confidencial e exclusiva.
uso do destinatário. Pode conter privado e confidencial.
em formação. As informações, anexos e opiniões contidas neste documento.
E-mail é apenas do autor e não representa necessariamente.
as do London Scottish Bank PLC ou de quaisquer outros membros da London.
& gt; Se você não é o destinatário pretendido, você está proibido de qualquer.
divulgação, distribuição ou posterior cópia ou uso desta comunicação.
ou a informação contida nela ou a tomada de qualquer ação com base nela. Se vocês.
tenha recebido esta comunicação por engano, por favor notifique a Informação.
Gerente de Segurança na ISM & # 64; London-Scottish & # 46; com o mais breve possível e.
exclua a mensagem de todos os lugares no seu computador onde ela está armazenada.
& gt; Utilizamos software de verificação de vírus, mas não podemos garantir o.
segurança das comunicações electrónicas e aconselha-se que verifique qualquer uma.
anexos de vírus. Nós não aceitamos responsabilidade por qualquer perda.
resultante de qualquer corrupção ou alteração de dados ou importação de.
qualquer vírus como resultado do recebimento desta comunicação eletrônica.
& gt; As respostas a este e-mail podem ser monitoradas para operacional ou comercial.
razões. O London Scottish Bank PLC é regulado pelos Serviços Financeiros.
& gt; Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Esta comunicação eletrônica é confidencial e para uso exclusivo do destinatário. Pode conter informações privadas e confidenciais. As informações, anexos e opiniões contidas neste e-mail são de seu autor e não representam necessariamente as do London Scottish Bank PLC ou de quaisquer outros membros do London Scottish Group.
Se você não for o destinatário pretendido, você está proibido de qualquer divulgação, distribuição ou cópia ou uso adicional desta comunicação ou das informações nela contidas ou de tomar qualquer medida com base nela. Se você recebeu esta comunicação por engano, por favor notifique o Gerente de Segurança da Informação na ISM & # 64; London-Scottish & # 46; com o mais rápido possível e exclua a mensagem de todos os lugares em seu computador onde ela está armazenada.
Utilizamos software de varredura de vírus, mas não podemos garantir a segurança das comunicações eletrônicas, e é recomendável que você verifique se há vírus em anexos. Não nos responsabilizamos por qualquer perda resultante de qualquer corrupção ou alteração de dados ou importação de qualquer vírus como resultado do recebimento desta comunicação eletrônica.
As respostas a este e-mail podem ser monitoradas por motivos operacionais ou comerciais. O London Scottish Bank PLC é regulado pela Financial Services Authority.
Este e-mail foi verificado pelo sistema de segurança de e-mail MessageLabs.
Para cancelar a assinatura, envie um e-mail: users-unsubscribe & # 64; subversion & # 46; tigris.
Para comandos adicionais, e-mail: users-help & # 64; subversion & # 46; tigris.
Recebido em Wed Nov 8 14:17:00 2006.
Esta mensagem: [Message body] Próxima mensagem: Gundersen, Richard: "RE: RE: Estratégia de ramificação - Feature vs Release" Mensagem anterior: Duncan Murdoch: "Re: Ramificação estratégia - Feature vs Release" Talvez em resposta a: Gundersen, Richard : "Estratégia de ramificação - Feature vs Release" Próximo no tópico: Gundersen, Richard: "FW: RE: Estratégia de ramificação - Feature vs Release" Talvez responda: Gundersen, Richard: "FW: RE: Estratégia de Ramificação - Feature vs Release" Mensagens contemporâneas classificado: [por data] [por segmento] [por assunto] [por autor] [por mensagens com anexos]
Este é um email arquivado postado na lista de discussão Usuários do Subversion.
No comments:
Post a Comment