No Subversion, como devo configurar uma nova versão principal do meu aplicativo?

10

Estou prestes a começar o trabalho em uma nova versão (versão 4) do meu aplicativo comercial. Eu uso o Subversion.

Com base em suas experiências, erros e sucessos, como você recomendaria que eu configurasse a nova versão no Subversion?

Aqui estão algumas informações: Pretendo continuar lançando atualizações críticas na versão 3 por algum tempo após o lançamento da versão 4. No entanto, todo o desenvolvimento de novos recursos será exclusivo na versão 4.

Caso seja relevante: sou um desenvolvedor solo deste produto e provavelmente esse continuará sendo o caso.

EDIT: Estou ciente das tags e ramificações do SVN. Acho que preciso de uma estratégia ideal para usar tags e ramificações na minha situação.

version-control svn

— Steve McLeod
fonte

8

O que você quer fazer é criar Ramos . É como parece uma ramificação na sua árvore de origem, normalmente uma cópia da sua fonte quando você a libera. Você se comprometeria neste ramo para as atualizações críticas e criaria a atualização a partir desse ramo.

O que você está comprometendo agora seria o trunke você codificaria a versão 4 lá. Se alguma alteração importante for confirmada na versão 3 e você desejar tê-la na versão 4, faça uma mesclagem da ramificação (v3) para o tronco (v4) para trazer as alterações para o tronco.

Você também pode olhar para as tags , que são como ramificações, mas estão vinculadas a uma única versão, geralmente a última revisão de uma versão (ou a primeira).

— Karthik T
fonte

Ao criar uma ramificação da versão anterior, você também pode criar uma tag para cada atualização / lançamento criado. Dessa forma, você tem um ramo no qual se comprometer e pode usar as tags para criar qualquer versão anterior feita.

— Geerten

Etiquetas IIRC em svn não necessariamente conectar-se a versões individuais, eles são na verdade idênticas às sucursais em todos, mas intensão

— jk.

Na verdade, ramificações e tags são idênticas na implementação, são essencialmente cópias do código. É apenas por convenção que eles diferem, as tags destinam-se a apontar para uma revisão específica, enquanto o ramo deve ser um caminho de desenvolvimento alternativo.

— Karthik T,

3

Depende.

Você pode manter a versão 4 no tronco e continuar desenvolvendo na V4. A versão 3 seria uma ramificação que você atualizaria conforme necessário. O benefício dessa abordagem é que, se um problema crítico for descoberto na V3 que também está na V4, você poderá fazer uma mesclagem simples nos arquivos entre as ramificações.

A outra opção é criar um repositório totalmente novo para a V4. Isso lhe dará um novo começo. A desvantagem é que o histórico de alterações foi redefinido e você não poderá mesclar arquivos via Subversion. Você precisará usar um programa como o Beyond Compare para mesclar as alterações.

Pessoalmente, eu continuaria com a primeira abordagem. Crie uma ramificação V3 e mantenha o código e as atualizações nessa ramificação. O novo código V4 pode ser desenvolvido no porta-malas.

— Chuck Conway
fonte

2

Encontrei um excelente guia para essa situação :

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too.

— Steve McLeod
fonte

0

O que você está perguntando é sobre a estratégia de ramificação (e mesclagem) a ser usada. Portanto, assuma o cargo de karthik te tome como receita.

Para mais informações, leia os seguintes recursos:

SVN Red Book para o layout do repositório (repositórios únicos vs. multiprojetos)
Padrões de ramificação em seu contexto, você usará uma ramificação de liberação por versão principal
Padrões de Gerenciamento de Configuração de Software da teoria básica usada no Subversion (e em todos os outros sistemas CM). Veja lá os padrões , especialmente a linha de liberação lá.

— mliebelt
fonte