Gerenciando um repositório SVN secreto

5

O projeto no qual estou trabalhando é uma versão controlada pelo SVN, e a regra implícita no trabalho é cometer apenas quando um novo recurso estável é adicionado (para ter um histórico de revisão "limpo" sem reverter), então eu trabalho às vezes por alguns dias sem se comprometer.

No entanto, eu sou uma espécie de maníaco comprometido (vários commits por dia em meus projetos git anteriores) e este fluxo de trabalho não combina comigo. Idealmente, eu gostaria de desembolsar o projeto, comprometer a versão instável sob o "repositório de submarinos" e fundir-se no repositório estável sempre que o recurso estiver estável o suficiente (meus commits instáveis não devem aparecer no repositório estável). Como posso fazer isso?

Com o SVN: procurei Filiais de fornecedores e Externos mas não encontrei realmente o que quero.

Com o Git: é possível usar o Git no repositório instável disfarçado e o SVN para o repositório estabilizado sem conflitos entre os dois CVS durante as mesclagens?

    
por lucasg 21.03.2013 / 00:11
fonte

2 respostas

7

Com o Subversion, você pode operar em uma ramificação que, para todos os efeitos, manterá o código incompleto fora do tronco.

Com o Git você pode operar localmente antes de empurrar todas as suas alterações para o mestre, ou como com o subversion você pode operar em vários ramos.

A principal vantagem de usar o Git sobre subversão, além do fato de ser um DVCS, é que a fusão é muito mais trivial do que no Subversion.

How can I do this ?

Faça o seu trabalho de desenvolvimento em um ramo para o seu VCS / DVCS de sua preferência. Somente mescle de volta ao tronco quando seu recurso estiver estável e você estiver satisfeito com isso.

With Git : is it possible to use Git on the undercover unstable repo and SVN for the stabilized repo without conflicts between the two CVS during merges ?

Esta pergunta / resposta no Stack Overflow mostra como sincronize e empurre o Git para o Subversion. Espero que ele ofereça o nível de detalhes técnicos que você precisa.

    
por 21.03.2013 / 00:35
fonte
0

Eu usaria a ferramenta de gerenciamento de patch Quilt. É muito leve e eficiente para fazer inúmeras pequenas alterações em uma árvore grande e simples de usar.

Quando chega a hora de se comprometer com o grande repositório, você pode aplicar todos os patches e fazer um grande commit ou enviá-los um por um.

Com o Quilt você pode ser um perfeccionista, porque é fácil reescrever a história. Você pode navegar para cima e para baixo na pilha de patches e consertar seu trabalho antigo, essencialmente aperfeiçoando cada patch. Se você migrar seus patches individualmente para um sistema de controle de versão, tudo isso parecerá uma unidade de trabalho perfeita. Todas as mudanças logicamente independentes pertencentes a esse trabalho estão em vários patches separados e, ainda assim, não há evidências de que tenha havido depuração, já que não há alterações repetidas no mesmo código para que funcione.

    
por 21.03.2013 / 02:37
fonte