Como gerenciar efetivamente o controle de origem para o projeto com fonte aberta e fechada?

5

Atualmente, estou trabalhando em um projeto que tem uma "edição da comunidade" de código aberto e um conjunto de recursos de código fechado para clientes pagantes. Um dos pontos problemáticos neste momento é descobrir como lidar com a manutenção da fonte compartilhada em sincronia entre os projetos.

Usamos o Mercurial para controle de código-fonte, e a peça de código aberto é enviada para o CodePlex e o Kiln, enquanto a peça de código fechado é enviada apenas para o Kiln. Atualmente, estamos mantendo-os em repositórios separados com referências de projeto no repositório de código aberto, onde aplicável.

Esta é realmente a melhor maneira de lidar com esse tipo de situação, ou se há algo que estou perdendo (como usar um subrepositório dentro do repositório de código-fonte fechado para conter a parte de código aberto) que pode ser mais fácil e mais limpo trabalhar com?

    
por Sean 10.08.2011 / 21:48
fonte

2 respostas

3

O benefício real da sua idéia de subrepositório é que ela associa as dependências de revisão entre os dois projetos. Em outras palavras, se um novo recurso de código fechado depende de uma versão de código aberto, quando alguém obtém um, obtém automaticamente o outro. Se você voltar a uma revisão de código fechado anterior para fazer um hotfix, você receberá automaticamente a revisão de código aberto com a qual você originalmente a criou. Existem outras maneiras, como configurar ou construir scripts, para gerenciar esses tipos de dependências, mas elas são mais difíceis de manter.

    
por 10.08.2011 / 22:12
fonte
1

Pelo que eu posso dizer, você está essencialmente trabalhando em dois "projetos": um código aberto, o outro código fechado. Não vejo um problema se esses dois "projetos" forem mantidos separados (isto é, mantidos em repositórios separados).

O modo como você gerencia esses dois "projetos" depende muito de como eles são projetados individualmente e de quão bem um pode ser integrado ao outro. Por exemplo, se um dos "projetos" for uma biblioteca de código fechado, o outro "projeto" de código aberto poderá integrar e usar essa biblioteca sem ter acesso à origem. Tenho a sensação de que você já está fazendo isso. Você pode gerenciar essa separação tendo equipes separadas responsáveis por cada "projeto" e coordenando entre si quando necessário.

    
por 10.08.2011 / 21:59
fonte