Atualmente, temos um repositório do subversion com o seguinte layout:
Eu acredito que este é um layout ruim, mas no momento é difícil mudar completamente.
Pessoalmente, eu não gosto de subversão, devido principalmente ao longo tempo que leva para verificar o histórico, e também que a ramificação e a mesclagem são complicadas, etc., então eu realmente quero usar o git em vez disso. Infelizmente, não podemos simplesmente mudar para o git, pois a capacidade mental de alguns pode ser muito grande, então eu estava olhando para o git-svn para ver se eu poderia usar isso para resolver o problema.Infelizmente, isso acaba diretamente em uma situação ruim, pois quero dividir cada projeto em um repositório do git e não quero ter que recriar o checkout do git-svn em cada computador em que trabalho. então eu acho que existe a possibilidade de criar algum tipo de git transparente ← → svn proxy / gateway, de modo que um push para esse repositório “compromete” o svn repo, e um commit no svn repo atualiza o git repo. / p>
O Google não é meu amigo, só encontrei ajuda de uso genérico para usar o git-svn, então eu pergunto se você tem algumas boas ideias para fazer isso.
Para o Git / Svn gateway transparente você pode usar o SubGit , ele atende aos seus requisitos muito bem, exceto que, no momento, ele suporta apenas um simples single -project (/ trunk, / branches, / tags) ou layouts multi-project (/ project / trunk, ...).
Se você não controla ou não quer mexer com o servidor Subversion, então você não pode usar o SubGit. O que você poderia fazer neste caso é ter um repositório git sincronizado automaticamente para cada tronco. Nossa equipe trabalha dessa forma - nós temos uma ponte git-Subversion que sincroniza as mudanças entre nosso repositório git de equipe e o tronco do projeto no repositório corporativo Subversion para que nosso uso de git seja transparente para outros usuários do Subversion.
A configuração é descrita com mais detalhes no link .
Usamos essa configuração em produção há mais de um ano.
Eu acho que a maior advertência da configuração é que as ramificações do git serão esmagadas em um commit durante a mesclagem para o trunk. Para nós isso não é problema - usamos ramos de tarefas de curta duração e os consideramos leves, efêmeras "unidades de trabalho" que podem ir para a linha principal em um único pedaço - e o histórico da ramificação é retido no git.
Você basicamente tem duas opções:
Permita que o git-svn no lado do cliente resolva o problema. Seus checkouts iniciais demorarão um pouco, mas podem dar a você os mesmos recursos de um svn checkout nativo (incluindo push e pull through git svn dcommit e git svn [fetch|rebase] ), e se você clonar com --stdlayout , ficará cheio suporte de ramificação e marcação. (Eu faço isso na minha empresa - eu sou um dos dois funcionários que usa o git com o servidor svn, e eu não tenho nenhum problema.)
Clone o repositório com o git-svn em outro servidor (ou até mesmo no mesmo servidor) e, em seguida, inicie a hospedagem do git nesse repositório. Então você tem um repositório nativo do git, com todos os dados do svn nele antes.
Se você não quiser "git svn clone" em cada computador, você pode: