Técnicas avançadas de subversão, o que estou perdendo?

Comecei a usar o SVN há cerca de 9 meses e tem sido um divisor de águas, para dizer o mínimo. Embora eu ainda esteja um pouco perdido. Eu sinto que há muito mais do que preciso aproveitar para realmente aprimorar meu desenvolvimento de aplicativos.

Por exemplo

Eu gostaria de poder colocar em quarentena quaisquer alterações voláteis / importantes em algum tipo de 'sub-repositório' ou algo assim. Estou descobrindo que grandes mudanças estão impedindo pequenas correções de bugs que são bastante urgentes. Como posso enviar uma atualização simples sem enviar código incompleto ou quebrado?

Para abordar seu exemplo, você tem três possibilidades para fazer isso:

1. Você pode confirmar arquivos únicos. Se você usa um IDE para acessar o Repositório, é provável que ele tenha uma visão para selecionar ou desmarcar arquivos únicos antes de confirmar. Na linha de comando, você digita svn commit file1 path1/file2 path2para confirmar arquivo1, caminho1 / arquivo2 e todas as alterações no caminho2.
2. Você pode fazer diferentes cópias de trabalho. Você trabalha em seu grande recurso em sua cópia de trabalho padrão e obtém as informações sobre o bug urgente. Você pode fazer o checkout do seu repositório em um diretório diferente e corrigir o erro nesta segunda cópia de trabalho. Você pode até verificar apenas um subdiretório com o componente em que o erro ocorre. Após a correção do bug, você pode confirmar em sua segunda cópia de trabalho sem comprometer seu trabalho no grande recurso. EDIT: Esse caminho também é descrito na resposta de Anna Lear.
3. Você cria uma ramificação para o trabalho em seu recurso. Para isso você usa o comando copy. Se você usar o layout padrão para seu repositório (diretórios com o projectname e subdiretórios com os nomes tronco, tags e ramos, tronco, contendo o projeto), você pode usar o svn-copy-comando como segue para criar o ramo: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Agora você pode mudar sua cópia de trabalho para o novo local: svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. Se você alternar no modo de correção de erros, confirma suas alterações reais, alterne sua cópia de trabalho de volta para o tronco, corrija o erro e confirme e troque a cópia de trabalho de volta à sua ramificação de recursos. Se você estiver pronto para desenvolver o recurso, poderá mesclá-lo novamente ao tronco.

Para o caso simples descrito, você normalmente usa o número 1 (eu uso com mais frequência), às vezes o número 2. Trabalhar com ramificações (caso nº 3) é mais complicado ( leia mais ), mas permite mais truques. Mas ramificações que correspondem à sua descrição de um sub-repositório.

Além do seu exemplo, não posso dizer muito. Há muitas coisas sobre o Subversion, mas não sei o que você já usa e o que precisa para o seu projeto. Para saber mais sobre o SVN, o SVN-Book é um ótimo recurso: http://svnbook.red-bean.com/

Você pode verificar o código em diferentes caixas de proteção, em vez de apenas tirar uma cópia e fazer todas as alterações lá.

Então você pode ter uma estrutura de pastas que é mais ou menos assim:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

etc.

Todos esses itens podem ser retirados do mesmo local no seu SVN, por exemplo http://mysvnrepo/trunk.

Dessa forma, você pode confirmar a partir da sua sandbox de correção de erros sem afetar os de desenvolvimento de recursos, embora seja necessário executar a svn updatepartir de outras sandboxes para obter as alterações confirmadas para a correção de erros.

Você já olhou os Ramos do Subversion ?

Uma técnica comum é manter o tronco estável, aplicando correções críticas conforme necessário. Em seguida, você cria uma ramificação para cada nova parte significativa do trabalho. Os desenvolvedores que trabalham nesse projeto fazem check-out da filial e se comprometem com ela. Não afeta o tronco até que você decida mesclar a ramificação de volta ao tronco principal como parte de sua integração final.

Outra abordagem é ter uma ramificação para uma versão específica, para evitar que qualquer outro trabalho seja feito acidentalmente no tronco, causando problemas. Você pode corrigir o 'Release Branch' conforme necessário e depois dobrá-las de volta ao tronco quando estiver pronto.

Seus desenvolvedores podem fazer check-out de várias cópias de trabalho - o tronco e quaisquer ramificações - ou podem trocar entre o tronco e uma ramificação específica com o svn switchcomando

Eu não recomendo ter muitas cópias de trabalho 'sandbox' que você faz checkout separadamente, pois (a) isso proíbe a colaboração com outras pessoas e (b) será muito fácil cometer acidentalmente alterações que ainda não estão funcionando no tronco principal.

O tamanho atual da minha cópia de trabalho é de 10 GB, com mais de 50.000 arquivos. Posso ter várias cópias para diferentes ramos, mas leva um tempo apenas para criar a nova cópia!

Quando um bug urgente chega, eu geralmente salvo todas as minhas alterações em um patch, reverto tudo, trabalho no bug e confirmao e aplico o patch que eu salvei ... Muito mais fácil e rápido do que obter uma nova cópia de trabalho. Se eu precisasse fazer isso com frequência, teria duas cópias de trabalho: uma para alterações de longo prazo e outra para correções de bugs.