Apr23
Não sei se é oficial (nem mesmo se estou atrasado comentando isso), mas vi agora que passaram a constar alguns tickets no Lighthouse: http://rails.lighthouseapp.com/
Agora a logística parece ser Github + Lighthouse. O Github é muito bacana, já tem vários forks do Rails, o último que vi é um esforço para implementar características thread-safe.
Legal, vamos acompanhar o progresso da migração 
UPDATE: Pois é, passei batido no feed do weblog.rubyonrails.com e não vi o anúncio oficial hehe. Não só o Rails foi para o Lighthouse, mas também o Capistrano e Prototype. Acontece 
Mar9
Este cenário surgiu da necessidade de sincronizar o desenvolvimento de mais pessoas num projeto Rails (usando GIT), no que diz respeito a vendor branches externos (plugins). Quando se usa SVN, instalar plugins no Rails com ./script/plugin install -x parece uma maravilha até o momento que você começa a alterar seus plugins.. Quando faz isso, não pode comitá-los, e fica no impasse sobre o que fazer. Nem preciso comentar o quão estranho seria mandar patchs para equipe…
As premissas, antes de tudo, eram:
- Não usar SVN.
- Flexibilidade para SVN e GIT como repositórios remotos.
- 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.
continue reading »
