git-svn-helpers

git-svn-helpers é uma coleção de ferramentas de linha de comando que simplifica bastante usando git para repositórios SVN.
O objetivo principal do git-svn-helpers é fazer com que a criação de um repositório git local depois de svn checkout existente um "acéfalo".
Ele também aborda usando um único repositório git-svn para trabalhar em vários checkouts de (geralmente) ramos diferentes e alternar entre eles.
Uso básico (Exemplo)
Sumário executivo:
> Caminho cd / to / svn / repo
> Gitify
Aqui está uma sessão de exemplo:
> Cd / tmp
> Svn co https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 plone.app.form
A 1.1 / setup.py
...
Check-out 27228 revisão.
> Cd plone.app.form
> Gitify
No repositório git encontrado em /Users/tomster/.gitcache/.
Iniciando a clonagem em cache.
Analisando svn log ...
Clonagem https://svn.plone.org/svn/plone/plone.app.form/ de r10593: 27155 em /Users/tomster/.gitcache/
Inicializado repositório Git vazio no /Users/tomster/.gitcache/plone.app.form/.git/
...
Git branch 'local / 1.1 "está agora a seguir ramo svn' 1.1 ':
# No ramo local / 1.1
nada a cometer (diretório de trabalho limpo)
> Git branch
* Local / 1.1
& Nbsp; mestre
Pontos a serem observados:
& Nbsp; * gitify limitado a clonagem para as revisões encontrados no log do SVN da raiz do pacote (aqui https://svn.plone.org/svn/plone/plone.app.form/). Uma grande economia de tempo, especialmente em grandes repositórios (como plone.collective)
& Nbsp; * gitify criado o repositório git em ~ / .gitcache não no lugar
& Nbsp; * gitify criou uma filial local local / 1.1 que segue a (remota) svn ramo 1.1 e ligado a ele
múltiplos check-outs
Na prática, muitas vezes você vai trabalhar com diferentes cópias locais de um determinado repositório, ou seja, no tronco e em uma filial recurso. Foi quando o diretório .gitcache criado acima vem a calhar. Vamos seguir nosso check-out anterior fora do caminho e criar um check-out de manutenção que segue tronco:
> Cd ..
> Mkdir recurso de ramo
> Plone.app.form mv longa-filial /
> Manutenção mkdir
> Manutenção de cd /
> Svn co https://svn.plone.org/svn/plone/plone.app.form/trunk plone.app.form
A plone.app.form / setup.py
...
& Nbsp; U plone.app.form
Check-out 27228 revisão.
O que acontece se corremos gitify aqui ?:
> Cd plone.app.form /
> Gitify
Git branch 'local / trunk "está agora a seguir svn ramo" tronco ":
# No ramo local / tronco
nada a cometer (diretório de trabalho limpo)
Observe, que esta operação foi muito mais rápido, já que agora tenho usado o repositório git existente no diretório cache. Isso pode ser ainda mais evidenciado por olhar para as filiais locais disponíveis agora:
> Git branch
& Nbsp; local / 1.1
* Local / tronco
& Nbsp; mestre
Advertências
.git 'Reciclagem' dessa maneira funciona (talvez surpreendentemente) bem na prática, mas você precisa manter em mente o seguinte:
Todos os checkouts compartilham o mesmo índice!
Vamos dar uma olhada no que isso significa, alternando de volta ao nosso ramo de recurso:
> Cd ../../feature-branch/plone.app.form/
> Git status
# No ramo local / tronco
# Mudou, mas não atualização:
# (Use "git add / rm ..." para atualizar o que será comprometido)
# (Use "git checkout - ..." para descartar as alterações no diretório de trabalho)
#
# Modificados: docs / History.txt
...
# Excluído: plone / app / form / kss / tests / test_kss.py
...
#
# arquivos Untracked:
# (Use "git add ..." para incluir em que será comprometido)
#
# Plone / app / form / tests / test_kss.py
Wohah! O que aconteceu é que .git agora aponta para tronco e, assim, o comando status mostra a diferença entre isso e nosso ramo como modificações locais, uma vez que é o que o sistema de arquivos representa. Podemos verificar isso usando comando status subversões:
> Svn st

Ufa! Tudo em ordem! Mas o que fazer com git? Nós terminamos a trabalhar no tronco e quer voltar para o nosso ramo de funcionalidade, mas o índice git está tudo errado ?! Simples: basta executar novamente gitify:
> Gitify
Git branch 'local / 1.1 "está agora a seguir ramo svn' 1.1 ':
# No ramo local / 1.1
nada a cometer (diretório de trabalho limpo)
Basicamente, isso é tudo que você precisa para se lembrar quando se trabalha com vários check-outs do mesmo pacote: Sempre executar gitify ao alternar entre check-outs

O que é novo nesta versão :

• O repositório canônico está agora em https://github.com/collective. [Rossp]
• Corrigir a manipulação quando se muda para um ramo svn que já git tem uma filial local para. [Rossp]

O que é novo na versão 0.8:

• Faça o comando init acompanhar se o repositório SVN tem sido transferido para um outro ramo. Graças a Calvin Hendryx-Parker por relatar o problema. [Tomster]

O que é novo na versão 0.7:

• Use cópias completas em vez de links simbólicos para criar cópias de trabalho. Isso evita o problema de ter o repositório git svn e fora de sincronia quando se trabalha com várias cópias do mesmo repositório e reduz muito o risco de conflitos.
• Isto significa também, que o comando buscar agora só funciona com o cache, sem modificar a cópia de trabalho (tornando-o seguro para ser executado via crontab, por exemplo)
• Running gitify contra uma cópia de trabalho de estilo antigo produzirá um erro. Basta apagar o link simbólico e re-executar remédios gitify que, no entanto.
• Outro efeito, é que o comando init agora só é necessário uma vez para cada cópia de trabalho (que já não é necessário re-executar o comando depois de alternar entre diferentes cópias de trabalho do mesmo repositório).
• gitify conseguinte, já não tem como padrão o comando init (assim como nem git svn nem fazer nada w / o fornecimento de uma ação explícita). Além disso, ele foi renomeado de gitify (de volta) para o init. [Tomster]
• Permitir a ajuda, --version e buscar comandos para executar diretórios fora .svn [tomster]

O que é novo na versão 0.5:

• comando Adicionado atualização gitify, que realiza um rebase git-svn operação para a atual versão SVN, mas também lida com as alterações locais não confirmadas gracelully (ao contrário git svn mas como svn faz)
• No mais usar o módulo de registro para o feedback do usuário. Essa idéia foi bastante equivocada

O que é novo na versão 0.4:

• Refatorada pontos a entrada de usar apenas gitify. Todos os outros comandos são agora sub-comandos de gitify:
• gs-commit foi substituído por impulso gitify
• gs-fetch foi substituído por gitify buscar
• uso Adicionado e saída da ajuda para cada comando.
• Removido o ponto de entrada gs-clone como foi sempre apenas utilizado em conjunto com o principal comando gitify de qualquer maneira.
• Use o log adequado em vez de apenas imprimir para stdout
• Adicionado testes abrangentes, incluindo testes funcionais que cobrem todo o update / cometer ciclo de clonar um repositório SVN e cometer voltar a ele.

O que é novo na versão 0.3.1:

• CORREÇÃO: Não use aliases personalizados, como eles não podem ser instalados. Isso resolve http://github.com/tomster/git-svn-helpers/issues#issue/2
• CORREÇÃO: Listar explicitamente ElementTree como dependência Isso resolve http://github.com/tomster/git-svn-helpers/issues#issue/1)

O que é novo na versão 0.3 Beta:

• Adicionado o comando que ajuda a cometer volta para gs-commit svn e mantendo git e SVN em sincronia

O que é novo na versão 0.2 Beta:

• Adicionado comando que ajuda a manter o cache os gs-fetch up-to-date

Requisitos :

• Python