git-svn-helpers

git-svn-hjælpere er en samling af kommandolinje værktøjer, der forenkler hjælp git til SVN repositories.
git-svn-hjælpere vigtigste mål er at gøre at oprette et lokalt git repository efter et eksisterende svn checkout en "no-brainer".
Den behandler også bruge en enkelt git-svn repository til at arbejde på flere kasser af (sædvanligvis) forskellige grene og skifte mellem dem.
Grundlæggende brug (eksempel)
Executive summary:
> Cd sti / til / svn / repo
> Gitify
Her er et eksempel session:
> Cd / tmp
> Svn co https://svn.plone.org/svn/plone/plone.app.form/branches/1.1 plone.app.form
En 1.1 / setup.py
...
Tjekket ud revision 27.228.
> Cd plone.app.form
> Gitify
Ingen git repository fundet i /Users/tomster/.gitcache/.
Start kloning i cache.
Analyse svn log ...
Kloning https://svn.plone.org/svn/plone/plone.app.form/ fra r10593: 27.155 i /Users/tomster/.gitcache/
Initialiseret tom Git repository i /Users/tomster/.gitcache/plone.app.form/.git/
...
Git gren 'lokalt / 1.1' følger nu svn filial «1.1 ':
# On gren lokal / 1.1
intet at begå (arbejdskatalog ren)
> Git gren
* Lokale / 1.1
& Nbsp; mester
Punkter at bemærke:
& Nbsp; * gitify begrænset kloningen til revisionerne fundet i svn log af pakken rod (her https://svn.plone.org/svn/plone/plone.app.form/). En stor tidsbesparelse, især på store depoter (såsom plone.collective)
& Nbsp; * gitify skabte git repository på ~ / .gitcache ikke på plads
& Nbsp; * gitify oprettet en lokal afdeling lokal / 1.1, der følger den (fjern) svn gren 1.1 og skiftede til det
Flere check out
I praksis vil man ofte arbejde med forskellige lokale kopier af en given repository, dvs. på stammen og på en funktion gren. Det er, når .gitcache mappe oprettet ovenfor kommer i handy. Lad os flytte vores tidligere checkout af vejen og skabe en vedligeholdelse kassen, der følger kuffert:
> Cd ..
> Mkdir feature-filial
> Mv plone.app.form feature-filial /
> Mkdir vedligeholdelse
> Cd vedligeholdelse /
> Svn co https://svn.plone.org/svn/plone/plone.app.form/trunk plone.app.form
En plone.app.form / setup.py
...
& Nbsp; U plone.app.form
Tjekket ud revision 27.228.
Hvad sker der, hvis vi kører gitify her ?:
> Cd plone.app.form /
> Gitify
Git gren 'lokalt / bagagerum' følger nu svn filial «bagagerum ':
# On gren local / bagagerum
intet at begå (arbejdskatalog ren)
Bemærk, at denne operation gik meget hurtigere, da vi nu har brugt den eksisterende git repository i cachen bibliotek. Dette kan yderligere dokumenteres ved at se på de tilgængelige lokale afdelinger nu:
> Git gren
& Nbsp; lokal / 1.1
* Lokale / trunk
& Nbsp; mester
Advarsler
»Genanvendelse« .git på denne måde virker (måske overraskende) godt i praksis, men du skal holde følgende i tankerne:
Alle kasserne deler samme indeks!
Lad os tage et kig på, hvad dette betyder ved at skifte tilbage til vores funktion filial:
> Cd ../../feature-branch/plone.app.form/
> Git status
# On gren local / bagagerum
# Ændret men ikke opdateret:
# (Brug "git tilføje / rm ..." for at opdatere, hvad der vil blive begået)
# (Brug "git checkout - ..." for at kassere ændringer i arbejdskapitalen mappe)
#
# Ændret: docs / HISTORY.txt
...
# Slettet: Plone / app / formular / KSS / tests / test_kss.py
...
#
# usporede filer:
# (Brug "git tilføje ..." for at medtage i, hvad der vil blive begået)
#
# Plone / app / formular / tests / test_kss.py
Wohah! Hvad er der sket, er, at .git nu peger på stammen og dermed status kommandoen viser forskellen mellem denne og vores afdeling som lokale ændringer, da det er hvad filsystemet repræsenterer. Vi kan bekræfte dette ved at bruge subversions status kommando:
> Svn st

Pyha! Alt i orden! Men hvad så med git? Vi er færdig med at arbejde på stammen og ønsker at komme tilbage til vores funktion filial, men git indekset er helt forkert ?! Simple: bare re-run gitify:
> Gitify
Git gren 'lokalt / 1.1' følger nu svn filial «1.1 ':
# On gren lokal / 1.1
intet at begå (arbejdskatalog ren)
Dybest set, det er alt hvad du behøver at huske, når du arbejder med flere check-out af en bestemt pakkerejse: Kør altid gitify når du skifter mellem check out

Hvad er nyt i denne udgivelse :

• cannonical repository er nu i https://github.com/collective. [Rossp]
• Fastgør håndtering ved skift til en svn gren, der git allerede har en lokal filial for. [Rossp]

Hvad er nyt i version 0.8:

• Gør init kommando følge med, hvis svn repository har været skiftede til en anden gren. Takket være Calvin Hendryx-Parker for at rapportere problemet. [Tomster]

Hvad er nyt i version 0.7:

• Brug fuld kopier i stedet for symlinks at skabe arbejdsvilkår kopier. Derved undgår man problemet med at have git og svn repository synkroniseret, når du arbejder med flere kopier af samme repository og i høj grad reducerer risikoen for konflikter.
• Det betyder også, at den hente kommandoen nu kun fungerer på cachen uden at ændre arbejdskopi (hvilket gør det sikkert at køre via crontab, for eksempel)
• Løb gitify mod en gammeldags arbejdskopi vil producere en fejl. Du skal blot slette den symbolske henvisning og gentage gitify retsmidler, dog.
• En anden effekt er, at init kommandoen nu er kun nødvendig en gang for hver arbejdsdag kopi (det er ikke længere nødvendigt at køre hele kommandoen efter skifte mellem forskellige arbejdsmetoder kopier af den samme repository).
• gitify derfor ikke længere som standard init kommando (ligesom hverken git eller svn gøre noget w / o levere et eksplicit handling). Også er det blevet omdøbt fra gitify (tilbage) for at init. [Tomster]
• Tillad den hjælp, --version og hente kommandoer til at køre uden .svn mapper [tomster]

Hvad er nyt i version 0.5:

• Tilføjet gitify opdatering kommando, der udfører en git-svn Rebase operation for den aktuelle svn checkout men håndterer også uudnyttede lokale ændringer gracelully (i modsætning til git svn men ligesom svn gør)
• ikke længere bruge logning modul til brugerfeedback. Denne idé var temmelig misforstået

Hvad er nyt i version 0.4:

• refactored den indgange til bare bruge gitify. Alle andre kommandoer er nu sub-kommandoer i gitify:
• GS-commit er blevet erstattet med gitify tryk
• GS-hentning er blevet erstattet med gitify hente
• Tilføjet brug og hjælp output for hver kommando.
• Fjernet GS-klonen indgang som det var kun nogensinde brugt sammen med de vigtigste gitify kommando alligevel.
• Brug korrekt logning i stedet for bare at udskrive til stdout
• Tilføjet omfattende tests, herunder funktionelle tests, der dækker hele opdatering / begå cyklus af kloning en svn repository og begå tilbage til den.

Hvad er nyt i version 0.3.1:

• Bugfix: Brug ikke tilpassede aliaser, som de måske ikke installeret. Dette løser http://github.com/tomster/git-svn-helpers/issues#issue/2
• Bugfix: Eksplicit liste elementtree som afhængighed Dette løser http://github.com/tomster/git-svn-helpers/issues#issue/1)

Hvad er nyt i version 0.3 Beta:

• Tilføjet af GS-begå kommando, som hjælper begå tilbage til svn og holde git og svn i sync

Hvad er nyt i version 0.2 Beta:

• Tilføjet af GS-hente kommando, som hjælper med at holde cachen up-to-date

Krav :

• Python