git-svn-helpers

git-svn-aiutanti è una raccolta di strumenti a linea di comando che semplifica notevolmente utilizzando git per repository SVN.
L'obiettivo principale di git-svn-aiutanti è quello di rendere la creazione di un repository git locale a seguito di un checkout svn esistente un 'no-brainer'.
Si affronta anche utilizzando un unico repository git-svn per lavorare su più estrazioni di (di solito) diversi rami e di passare.
Utilizzo base (esempio)
Sintesi:
> Percorso cd / a / svn / repo
> Gitify
Ecco un esempio di sessione:
> Cd / tmp
> Svn co https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 plone.app.form
A 1.1 / setup.py
...
Il check-out 27228 revisione.
> Cd plone.app.form
> Gitify
Nessun repository git trovato in /Users/tomster/.gitcache/.
Avvio clonazione in cache.
Analizzando svn log ...
Clonazione https://svn.plone.org/svn/plone/plone.app.form/ da r10593: 27155 in /Users/tomster/.gitcache/
Inizializzata repository Git vuoto in /Users/tomster/.gitcache/plone.app.form/.git/
...
Git filiale 'locale / 1.1' sta seguendo ramo svn '1.1':
# On ramo locale / 1.1
niente a commettere (directory di lavoro pulito)
> Ramo git
* Locale / 1.1
& Nbsp; maestro
Punti da notare:
& Nbsp; * gitify limita la clonazione alle revisioni presenti nel registro svn della radice del pacchetto (qui https://svn.plone.org/svn/plone/plone.app.form/). Un grande risparmio di tempo, soprattutto su grandi repository (ad esempio plone.collective)
& Nbsp; * gitify creato il repository git a ~ / .gitcache non luogo
& Nbsp; * gitify creato una filiale locale locale / 1.1 che segue la (remota) svn ramo 1.1 e passato a esso
di più check-out
In pratica ti capiterà spesso di lavorare con diverse copie locali di un dato repository, cioè sul tronco e su un ramo di caratteristica. Questo è quando la directory .gitcache creata precedentemente viene in aiuto. Passiamo il nostro checkout precedente fuori strada e creare un checkout di manutenzione che segue tronco:
> Cd ..
> Mkdir feature-branch
> Plone.app.form mv feature-branch /
> Manutenzione mkdir
> Manutenzione 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
Il check-out 27228 revisione.
Che cosa succede se corriamo gitify qui ?:
> Cd plone.app.form /
> Gitify
Git filiale 'locale / trunk' sta seguendo svn branch 'tronco':
# On ramo locale / trunk
niente a commettere (directory di lavoro pulito)
Si noti che questa operazione è andato molto più veloce, come ora abbiamo usato il repository git esistente nella directory cache. Questo può essere ulteriormente evidenziato, cercando in sezioni locali disponibili ora:
> Ramo git
& Nbsp; local / 1.1
* Locale / trunk
& Nbsp; maestro
Avvertenze
.git 'Recycling' in questo modo funziona (forse sorprendentemente) bene in pratica, ma è necessario tenere presente quanto segue:
Tutte le casse condividono lo stesso indice!
Diamo un'occhiata a ciò che questo significa passando di nuovo al nostro ramo di caratteristica:
> Cd ../../feature-branch/plone.app.form/
> Stato git
# On ramo locale / trunk
# Cambiato ma non aggiornato:
# (Uso "git add / rm ..." per aggiornare quello che sarà impegnata)
# (Use "git checkout - ..." per annullare le modifiche nella directory di lavoro)
#
# Modificati: docs / HISTORY.txt
...
# Cancellato: plone / app / form / KSS / test / test_kss.py
...
#
# file non tracciati:
# (Uso "git add ..." per includere in quello che sarà impegnato)
#
# Plone / app / form / test / test_kss.py
Wohah! Quello che è successo è che .git punti ora al tronco e quindi il comando di stato mostra la differenza tra questo e la nostra filiale come modifiche locali, dal momento che questo è ciò che il filesystem rappresenta. Possiamo verificare questo utilizzando comando status sovversioni:
> Svn st

Accidenti! Tutto in ordine! Ma cosa fare con git? Abbiamo finito di lavorare sul tronco e vogliamo tornare al nostro ramo di caratteristica, ma l'indice di Git è tutto sbagliato ?! Semplice: basta rieseguire gitify:
> Gitify
Git filiale 'locale / 1.1' sta seguendo ramo svn '1.1':
# On ramo locale / 1.1
niente a commettere (directory di lavoro pulito)
In sostanza, questo è tutto quello che dovete ricordare quando si lavora con più check-out dello stesso pacchetto: eseguire sempre gitify quando si passa il check-out

Cosa c'è di nuovo in questa versione :

• Il repository cannonical è ora in https://github.com/collective. [Rossp]
• Fissare il trattamento quando si passa a un ramo svn git che ha già una filiale locale. [Rossp]

Cosa c'è di nuovo in versione 0.8:

• Fare il comando init seguire lungo se il repository svn è stato passati a un altro ramo. Grazie a Calvin Hendryx-Parker per aver segnalato il problema. [Tomster]

Cosa c'è di nuovo in versione 0.7:

• Utilizza copie complete invece di link simbolici per creare copie di lavoro. Questo evita il problema di avere il repository git svn e fuori sincronia quando si lavora con più copie dello stesso repository e riduce notevolmente il rischio di conflitti.
• Questo significa anche, che il comando prendere ora funziona solo sulla cache senza modificare la copia di lavoro (il che rende sicuro di correre via crontab, ad esempio)
• Esecuzione gitify contro un copia di lavoro vecchio stile produrrà un errore. Basta eliminare il collegamento simbolico e rimedi gitify ri-esecuzione che, però.
• Un altro effetto è che il comando init è ora necessaria solo una volta per ogni copia di lavoro (non è più necessario eseguire nuovamente il comando dopo il passaggio tra le diverse copie di lavoro dello stesso repository).
• gitify pertanto nessun default più al comando init (proprio come non git svn, né fare nulla w / o la fornitura di un'azione esplicita). Inoltre, è stato rinominato da gitify (di nuovo) a init. [Tomster]
• Consenti l'aiuto, --version a prendere i comandi da eseguire directory al di fuori .svn [Tomster]

Cosa c'è di nuovo in versione 0.5:

• comando Aggiunto aggiornamento gitify, che svolge una rebase git-svn operazione per cassa svn corrente, ma gestisce anche le modifiche locali non impegnati gracelully (a differenza git svn, ma come svn fa)
• non usano più il modulo di registrazione per il feedback degli utenti. Questa idea era piuttosto fuorviante

Cosa c'è di nuovo in versione 0.4:

• refactoring punti l'ingresso di usare solo gitify. Tutti gli altri comandi sono ora sotto-comandi gitify:
• gs-commit è stato sostituito con push gitify
• gs-fetch è stato sostituito con gitify recuperare
• uso aggiunto e l'uscita di aiuto per ogni comando.
• Rimosso il punto di ingresso gs-clone come è stato sempre e solo usato insieme al comando principale gitify comunque.
• Usare un logging invece di stampare su stdout
• Aggiunto test completi, compresi i test funzionali che coprono l'intero aggiornamento / ciclo della clonazione di un repository svn e commettere di nuovo esso commesso.

Cosa c'è di nuovo nella versione 0.3.1:

• BUGFIX: non utilizzare alias personalizzati, come potrebbero non essere installati. Questo risolve http://github.com/tomster/git-svn-helpers/issues#issue/2
• BUGFIX: esplicitamente lista elementtree come dipendenza Questo risolve http://github.com/tomster/git-svn-helpers/issues#issue/1)

Cosa c'è di nuovo in versione 0.3 Beta:

• Aggiunti i comandi che aiuta a impegnarsi di nuovo a gs-commit svn e mantenere git svn e in sincronia

Cosa c'è di nuovo in versione 0.2 Beta:

• Aggiunto comando che aiuta a mantenere la cache dei gs-fetch up-to-date

Requisiti :

• Python