Pode diferentes clones git-svn do mesmo repositório SVN esperar para ser capaz de partilhar as alterações introduzidas, em seguida, git svn dcommit?

Question

Eu li uma grande quantidade de "vão de svn para git" e outros artigos "de fluxo de trabalho git-svn" na web, e ainda acho que eles muitas vezes lidar com situações excessivamente simples. Eles são muitas vezes alvo de caras que só querem usar git e cortar localmente, sem usar o poder do git, como puxar, buscar, fusão e similares entre vários desenvolvedores que todos teriam clonado no repositório SVN com git-svn, então ainda esperam para ser capaz de empurrar suas alterações a qualquer momento para o (oficial) repositório SVN, e voltar a trabalhar em git e compartilhar suas coisas etc.

Sempre que estes artigos admitir que você não pode fazer tudo o que você faria em git pura, as conseqüências e possíveis ups de parafuso são nunca explicou claramente (ou talvez seja só eu?). Mesmo a página man git-svn menciona ressalvas, mas não realmente de uma maneira extensa.

Com base no que eu li, eu sinto que poderia haver problemas quando git-svn é usado dessa maneira específica, que vou descrever abaixo. Alguém pode me dizer se estou certo sobre isso?

Aqui é o caminho "queria" de fazer as coisas:

1. Nós temos um projeto em um repositório SVN
2. O desenvolvedor A git-svn-clone é o svn repo. Ele começa a cortar as coisas localmente
3. Desenvolvedor B do git-svn-clone a mesma svn repo. Ele começa a cortar as coisas por conta própria.
4. Depois de fazer isso por algum tempo, possivelmente, acrescentando devs C / D / ..., e ter outros desenvolvedores que fazer "padrão" commits SVN para o repo original, os usuários git gostaria de compartilhar seu código e fazer todos os tipos de magia git.
5. Qualquer um desses usuários git gostaria de ser capaz de empurrar o agora fundido mudanças para o SVN (dcommit?)

A minha pergunta é: eu estou sonhando? Eu li há algum tempo, em um livro git eu acho, que git-svn-clone poderia criar repositórios git que são, naturalmente, um "espelho" do SVN repo, mas que repos git criado dessa forma por diferentes desenvolvedores teriam diferente " ids" e commits teria diferentes hashes. Então, o meu entendimento foi de que esses repos git não compartilhar qualquer antepassado git comum, e, portanto, não seria capaz de usar todos os comandos do git Você precisa dividir, fundir, e assim por diante. É verdade, vamos enfrentar problemas com este fluxo de trabalho?

Às vezes leio isso poderia ser feito, usando pelo menos um repositório "oficial" git nua, que seria o único a ser git-clonado-svn, e todos os usuários git teria que começar a formar este. Então você precisa de alguém que é responsável por este repo git central, e reúne as mudanças entre os devs Git, antes dcommiting tudo para o svn repo. Esta seria a única maneira para os usuários git para ser "inconsciente" que o repo git original vem do SVN, e iria deixá-los usar todos os comandos do git como eles gostam. A única pessoa que teria de ser fluente em git e SVN (e saber sobre git-svn ressalvas) seria o "gerente merge" (ou o que ele é chamado).

Am I mal entendido completamente git-svn advertências? Existe alguma maneira mais simples de fazer isso?

Answer 1

O problema é o passo 4 é claro. A dcommit tenta repetir seu histórico de local para o servidor. Dcommit finge que você é um cliente SVN. Agora, se o código que você está dcommitting não é só de você, isso é algo que é difícil de dcommit para SVN.

Aqui está o que os guru escreve sobre o assunto:

• Por uma questão de simplicidade e interoperar com SVN, é recomendado que todos os usuários git-svn clone, buscar e dcommit directamente a partir de o servidor SVN (o SVN remoto repositório que é), e evitar toda operações git-clone / tração / merge / PUSH entre repositórios git e ramos que ou são recuperados através svn git clone e que também são usados ??para empurrar changesets de volta para o SVN remoto repositório.
• O método recomendado de troca de código entre os ramos git e utilizadores é git formato de remendo e git am, ou apenas git svn dcommit ao SVN repositório.
• Uma vez que git svn dcommit usa svn git rebase internamente, quaisquer ramos git nós git push para antes git svn dcommit em -los vai exigir forçando uma substituição do ref existente no controle remoto repositório. Este é geralmente considerado uma má prática, consulte o documentação git-push para mais detalhes.
• Running merge git ou git pull não é recomendado em uma filial pretendemos git svn dcommit partir. SVN não representam fusões em qualquer razoável ou moda útil para que os usuários usando SVN Não consigo encontrar as fusões que fizemos. Além disso, se nós git merge ou git puxar de um ramo git que é um espelho de um ramo SVN, svn git dcommit pode comprometer com o mal galho.
• clone git faz não ramos clone sob a refs / remotes / hierarquia ou qualquer git-svn metadados, ou configuração. então repositórios criados e geridos com usando git-svn deve usar rsync para clonagem, se a clonagem é para ser feito em tudo.
• Não devemos usar a opção --amend de git commit em que a mudança já dcommitted. Isto é considerada má prática para --amend commits já empurrou a um repositório remoto para outros usuários, e dcommit com SVN é análogo àquele. Mais informações sobre este podem ser encontrados a modificação de uma única confirmação e Problemas com reescrevendo a história .

Answer 2

Eu tenho experimentado muito com isso ultimamente, e acho que conseguiu chegar a uma configuração que algo funciona. Sim, é um regime estrito só de rebase, sim é complicado, mas você começa a usar o Git para trabalhar localmente (velocidade, história, stash, índice, etc).

Você pode usar ramos nos bastidores quando você colaborar com outros usuários do Git em sua equipe eu acho, mas não pessoalmente tenho experimentado muito com isso. Contanto que você linearizar o log antes dcommitting ele deve funcionar.

Aqui está a versão curta (repete muito o que já foi dito):

1. Clone o repositório do Subversion em um repo "buscar" em um servidor central
2. Init um "nu" repo no mesmo servidor
3. Premir a partir do repo fecthing à repo nua
4. Have desenvolvedores clonar o repo nua e, em seguida,
   5. git svn init svnurl para configurar o controle remoto, git-svn e
   6. git update-ref refs/remotes/git-svn refs/remotes/origin/master assim git-svn tem um ponteiro para uma revisão
5. automaticamente (commit gancho) ter a "buscar" repo svn rebase, e empurrar para o repo nua
6. Os desenvolvedores puxar do repo nua com git pull --rebase
7. Os desenvolvedores git svn dcommit correndo primeiro tem que repetir o update-ref acima em caso de revisões mais recentes provenientes de SVN.

Há uma ilustração do fluxo de trabalho desta página (Eu preciso de mais pontos de reputação antes que eu possa inline imagem). Update: Aqui vamos nós:

Answer 3

O que eu costumava fazer, é criar um clone git svn inicial, então, compartilhou ele .git entre os programadores usando git, então tivemos exatamente as mesmas referências.
Pareceu funcionar corretamente como fomos capazes de usar "git específica apresenta" entre os usuários git, enquanto nós ficamos em uma árvore linear (ie rebasing em vez de juntar).

Answer 4

Assim que você entrar em "distribuídas" problema, você é melhor fora com um repo git bare clonado entre os desenvolvedores.
Em relação à fase de exportação e importação para o repositório SVN público, para outros para uso, os scripts
git2svn e svn2git pode ajudar encapsular a magia.

Outras considerações quando trabalham em Git e SVN repos são encontrados na questão " Fluxo de trabalho e ajuda com git, 2 projectos SVN e um único “workcopy” "

Answer 5

Há uma ferramenta que resolve o problema de compartilhamento de repositório Git sincronizado com o repositório Subversion.

SubGit é um espelho do lado do servidor Git-SVN bi-direcional.

Pode-se instalar SubGit no repositório Subversion e obter repositório Git automaticamente sincronizado com o SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit instalações pré-compromisso e pós-commit ganchos em repositório Subversion, pré-receber e pós-receber ganchos em repositório Git. Como resultado, imediatamente traduz modificações de entrada do SVN e Git lados. Depois de desenvolvedores de instalação SubGit pode usar qualquer cliente Git para clonar e trabalhar com o repositório Git.

SubGit não depende de git-svn, ele usa o seu próprio mecanismo de tradução nossa equipe desenvolveu. Mais detalhes sobre isso, você pode encontrar em SubGit vs. comparação git-svn . Documentação geral sobre SubGit está disponível aqui .

A versão 1.0 do SubGit precisa de acesso local para o repositório Subversion, ou seja, SVN e repositórios Git tem que residir no mesmo host. Mas com a versão 2.0 nós estamos indo para introduzir o modo de proxy Git, quando Subversion e Git repositórios pode ser localizado em qualquer lugar e apenas repositórios Git tem SubGit instalado neles, isto é, Subversion repositórios permanecem intocados.

SubGit é um produto comercial. Ele é gratuito para open-source, projeto acadêmico e também para projetos com até 10 committers.

Disclaimer: Eu sou um dos desenvolvedores SubGit

.

Answer 6

este post que sugere mantendo um ramo separado para sincronizar com o repositório Subversion, de modo que ainda será possível fazer envio / recepção no branch master.

Answer 7

Um dos problemas que percebo com git-svn é que ele armazena o git-svn-id no comentário cometer; porque reescreve que cometeu, ele muda-lo de SHA1, então você não pode empurrá-lo em qualquer lugar as pessoas estarão compartilhando-o.

Eu realmente prefiro bzr-svn porque em vez ele armazena o revid bzr na revisão SVN remoto usando as propriedades de revisão do SVN apresentam vez que significa que não reescrita revisão local. Ele também tem a propriedade desejada, que dois puxa independentes do mesmo ramo SVN irá resultar em ramos bzr idênticos e interoperáveis.