As premissas, antes de tudo, eram:

1. Não usar SVN.
2. Flexibilidade para SVN e GIT como repositórios remotos.
3. Possibilidade de trabalhar em ambiente multiusuário, ou seja, vários desenvolvedores.

Deixe-me explicar a primeira premissa: Usar Subversion implicaria em merges a cada atualização dos plugins. Independente da solução que fosse usada para o merge de um plugin (piston, svnmerge, svn_load_dirs), o Subversion não trabalha bem com arquivos removidos/renomeados/movidos. Seja qual for a estratégia, o fato de fazer merge em repositórios diferentes no Subversion é um “tiro no escuro”: você nunca sabe está realmente idêntico ao repositório que você sincronizou, principalmente quando há mudanças drásticas neles (arquivos removidos/renomeados/movidos), e vai deixando seu rastro de desorganização com o tempo. No site do Piston eles também comentam sobre isso.

Passei horas e horas pesquisando e rascunhando no papel estratégias com repositório central. A solução que mais se aproximou àquela que eu gostaria foi esta aqui, que trabalha com git-submodule.
Fantástica por sinal! Adorei o git-submodule. Como o GIT não permite fazer clones parciais, apenas de repositórios inteiros, achei que fosse a solução. Fiz vários testes, e quando eu havia compreendido muito bem o seu funcionamento, percebi que o git-submodule era muito peculiar para trabalhar com alterações, e certamente causaria confusões na equipe.
Mas essa solução é muito bacana. Se o objetivo for centralizar um repositório de plugins, essa solução pode muito bem ser avaliada.

Mas ela já mata a primeira e a segunda premissa: tem em sua base um servidor Subversion. Ao passo que alguns plugins vêm sendo gerenciados por GIT, já começariamos aqui a ter que colocar repositórios GIT no Subversion! Um retrocesso à nossa meta, na minha opinião

Enfim, o braid!

Até que encontrei o braid (O Fábio Akita já havia comentado sobre ele no Rails Podcast Brasil). O braid é uma ferramenta simples pra gerenciar vendor branches (no nosso caso, plugins do Rails) de repositórios diferentes. Mais ou menos um Piston para GIT.

Resumindo o funcionamento do braid: ele faz uma branch chamada braid/track e nela adiciona clones (git-svn init) para os seus plugins, e ainda faz o merge nesta branch. Quando julgar necessário, você faz merge com sua branch principal.

Experimentando

Para instalar o braid, faça:

1
2
3
4

$ git clone git://github.com/evilchelu/braid.git
$ cd braid
$ sudo gem install main open4
$ sudo ruby setup.rb

Com o braid instalado, inicie um projeto apenas para teste:

1
2
3
4
5
6
7
8

$ mkdir testing
$ cd testing
$ git init
$ echo "test" > file
$ git add file && git commit -m "import inicial"
 
# Jabá brazuca como exemplo: adicionar o plugin feito pelo Carlos Brando
$ braid add  http://plugins.nomedojogo.com/custom_resource_name --type svn vendor/plugins/custom_resource_name

Isto cria a seguinte estrutura:

1
2
3
4

$ git branch -a
  braid/track
* master
  braid/svn/vendor/plugins/custom-resource-name

Quando houver modificação no plugin, basta fazer:

1
2

$ braid update  # atualiza o plugin
$ git merge braid/track # merge com sua branch principal (master)

Bacana, mas e a equipe?

Num cenário real (como o que motivou essa estratégia), o repositório está num servidor central que os outros desenvolvedores fazem seus clones. Mas nesse repositório não ficarão os dados da branch recém criada. Então, como os desenvolvedores atualizarão os plugins?

Uma maneira é passar aos demais desenvolvedores os repositórios remotos para que eles adicionem manualmente no .git/config dos seus clones.

1
2
3
4
5
6
7
8
9
10
11

$ cat .git/config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
 
# esta parte aqui e mais eventuais outros plugins instalados:
[svn-remote "braid/svn/vendor/plugins/custom-resource-name"]
        url = http://plugins.nomedojogo.com/custom_resource_name
        fetch = :refs/remotes/braid/svn/vendor/plugins/custom-resource-name

Sim, isto funciona. Depois basta fazer um braid update.

Mas não é uma forma muito interessante. Ótimo seria explorar o arquivo que o braid cria automaticamente, chamado .braids, que mantém os dados dos vendor branches adicionados:

1
2
3
4
5
6
7

$ cat .braids 
--- 
vendor/plugins/custom_resource_name: 
  local_branch: braid/svn/vendor/plugins/custom-resource-name
  type: svn
  branch: master
  remote: http://plugins.nomedojogo.com/custom_resource_name

Uma maneira seria modificar o braid e adicionar a funcionalidade de ler este arquivo e adicioná-lo com comandos do GIT. O criador do braid já havia comentado que isso seria feito. Como ainda não foi feito e eu queria testar essa solução, criei um patch e enviei a ele.

Com este patch, um desenvolvedor pode fazer um clone do repositório e, em seguida, executar git rebuild, que reconstruiria a branch e os links remotos a partir do arquivo .braids.
Em breve será feito algo semelhante no braid, seja a partir deste patch ou um novo

É isso!
Vale lembrar que o braid ainda está amadurecendo. O gem, por exemplo, ainda nem foi publicado.
Se você tiver alguma outra idéia ou modelo, fique à vontade em comentar