git-svn - Online in de cloud

PROGRAMMA:

NAAM

git-svn - Bidirectionele werking tussen een Subversion-repository en Git

KORTE INHOUD

git svn [opties] [argumenten]

PRODUCTBESCHRIJVING

git svn is een eenvoudig kanaal voor wijzigingen tussen Subversion en Git. Het biedt een
bidirectionele stroom van wijzigingen tussen een Subversion en een Git-repository.

git svn kan een standaard Subversion-repository volgen, volgens de algemene regels
"trunk/takken/tags"-indeling, met de optie --stdlayout. Het kan ook takken volgen en
tags in elke lay-out met de opties -T/-t/-b (zie opties voor init hieronder, en ook de
klonen opdracht).

Zodra een Subversion-repository wordt gevolgd (met een van de bovenstaande methoden), wordt de Git-repository
kan worden bijgewerkt vanuit Subversion door de halen command en Subversion bijgewerkt vanuit Git door de
vastleggen opdracht.

COMMANDO'S

init
Initialiseert een lege Git-repository met extra metadatamappen voor git svn.
De Subversion-URL kan worden opgegeven als opdrachtregelargument, of als volledige URL
argumenten voor -T/-t/-b. Optioneel kan de doelmap worden opgegeven waarop moet worden gewerkt
als tweede argument. Normaal gesproken initialiseert deze opdracht de huidige map.

-T , --trunk= , -T , --tags= ,
-B , --takken= , -s, --stdlayout
Dit zijn optionele opdrachtregelopties voor init. Elk van deze vlaggen kan naar verwijzen
een relatief repositorypad (--tags=project/tags) of een volledige URL
(--tags=https://foo.org/project/tags). U kunt meer dan één --tags en/of opgeven
--branches opties, voor het geval uw Subversion-repository tags of branches plaatst
onder meerdere paden. De optie --stdlayout is een verkorte manier van instellen
trunk,tags,branches als de relatieve paden, wat de standaard van Subversion is. Indien aanwezig
van de andere opties die ook worden gegeven, hebben deze voorrang.

--geen-metadata
Kies het geenMetagegevens optie in de [svn-remote]-configuratie. Deze optie is dat niet
aanbevolen, lees de svn.noMetadata sectie van deze manpagina voordat u deze gebruikt
deze optie.

--gebruik-svm-props
Kies het gebruikSvmProps optie in de [svn-remote]-configuratie.

--gebruik-svnsync-props
Kies het gebruikSvnsyncProps optie in de [svn-remote]-configuratie.

--rewrite-root=
Kies het herschrijvenRoot optie in de [svn-remote]-configuratie.

--rewrite-uuid=
Kies het herschrijfUUID optie in de [svn-remote]-configuratie.

--gebruikersnaam=
Voor transporten waarvoor SVN de authenticatie afhandelt (http, https en gewone svn),
specificeer de gebruikersnaam. Voor andere transporten (bijvoorbeeld svn+ssh://) moet u opnemen
de gebruikersnaam in de URL, bijvoorbeeld svn+ssh://foo@svn.bar.com/project

--voorvoegsel=
Hierdoor kan men een voorvoegsel specificeren dat wordt voorafgegaan aan de namen van de afstandsbedieningen als
stam/takken/tags zijn gespecificeerd. Het voorvoegsel bevat niet automatisch a
afsluitende schuine streep, dus zorg ervoor dat u er een in het argument opneemt als dat is wat u wilt
wil. Als --branches/-b is opgegeven, moet het voorvoegsel een schuine streep bevatten.
Het instellen van een voorvoegsel (met een schuine streep) wordt in ieder geval sterk aanbevolen, zoals
uw SVN-tracking-referenties bevinden zich dan op "refs/remotes/$prefix/", welke is
verenigbaar with Git's het te bezitten. tracking op afstand ref lay-out (refs/remotes/$remote/).
Het instellen van een voorvoegsel is ook handig als u meerdere gedeelde projecten wilt volgen
een gemeenschappelijke opslagplaats. Standaard is het voorvoegsel ingesteld op oorsprong/.

Note
Vóór Git v2.0 was het standaard voorvoegsel "" (geen voorvoegsel). Dit betekende dat
SVN-tracking-referenties zijn op "refs/remotes/*" geplaatst, wat niet compatibel is met hoe
Git's eigen remote-tracking refs zijn georganiseerd. Als je nog steeds het oude wilt
standaard kunt u dit verkrijgen door --prefix "" op de opdrachtregel in te voeren
(--prefix="" werkt mogelijk niet als uw Perl's Getopt::Long < v2.37 is).

--negeer-paden=
Wanneer doorgegeven aan init or klonen deze reguliere expressie wordt bewaard als een configuratie
sleutel. Zien halen voor een beschrijving van --negeer-paden.

--include-paden=
Wanneer doorgegeven aan init or klonen deze reguliere expressie wordt bewaard als een configuratie
sleutel. Zien halen voor een beschrijving van --include-paden.

--no-minimaliseer-url
Bij het volgen van meerdere mappen (met behulp van --stdlayout, --branches of --tags
opties), zal git svn proberen verbinding te maken met de root (of het hoogste toegestane niveau)
van de Subversion-repository. Deze standaard maakt een betere tracking van de geschiedenis mogelijk
hele projecten worden binnen een repository verplaatst, maar kunnen problemen veroorzaken
opslagplaatsen waar leestoegangsbeperkingen gelden. Passeren
--no-minimaliseer-url zal git svn toestaan ​​URL's te accepteren zoals ze zijn, zonder dat te proberen
verbinding maken met een map op een hoger niveau. Deze optie is standaard uitgeschakeld als er slechts één is
URL/branch wordt bijgehouden (het zou weinig goeds doen).

halen
Haal niet-opgehaalde revisies op van de Subversion-afstandsbediening die we volgen. De naam van de
De sectie [svn-remote "..."] in het bestand $GIT_DIR/config kan als optioneel worden opgegeven
opdrachtregelargument.

Hierdoor wordt de rev_map indien nodig automatisch bijgewerkt (zie $GIT_DIR/svn/**/.rev_map.* in
het gedeelte BESTANDEN hieronder voor meer informatie).

--lokale tijd
Bewaar Git-vastleggingstijden in de lokale tijdzone in plaats van UTC. Dit maakt git inloggen
(zelfs zonder --date=local) toon dezelfde tijden als svn log in de lokale versie
tijdzone.

Dit heeft geen invloed op de samenwerking met de Subversion-repository
waarvan gekloond is, maar als je wilt dat je lokale Git-repository dat ook kan
samenwerken met de lokale Git-repository van iemand anders, gebruik dit ook niet
optie of u moet het allebei in dezelfde lokale tijdzone gebruiken.

--ouder
Alleen ophalen van de SVN-ouder van de huidige HEAD.

--negeer-paden=
Hierdoor kunt u een reguliere Perl-expressie specificeren die ervoor zorgt dat er wordt overgeslagen
alle overeenkomende paden vanaf het afrekenen bij SVN. De --negeer-paden optie moet overeenkomen
voor iedere halen (inclusief automatisch ophalen vanwege klonen, vastleggen, opnieuw baseren, enz)
op een bepaalde repository.

configuratiesleutel: svn-remote. .ignore-paden

Als de configuratiesleutel voor negeerpaden is ingesteld en de opdrachtregeloptie dat ook is
gegeven, zullen beide reguliere expressies worden gebruikt.

Voorbeelden:

Sla de map "doc*" over bij elke ophaalactie

--ignore-paden = "^doc"

Sla "takken" en "tags" van mappen op het eerste niveau over

--ignore-paths="^[^/]+/(?:branches|tags)"

--include-paden=
Hierdoor kunt u een reguliere Perl-expressie specificeren die de opname zal veroorzaken
van alleen overeenkomende paden vanaf het afrekenen bij SVN. De --include-paden optie zou moeten
match voor elke halen (inclusief automatisch ophalen vanwege klonen, vastleggen, opnieuw baseren,
etc) op een bepaalde repository. --negeer-paden heeft voorrang op --include-paden.

configuratiesleutel: svn-remote. .include-paden

--log-venstergrootte=
Ophalen logboekinvoer per verzoek bij het scannen van de Subversion-geschiedenis. De standaardwaarde is
100. Voor zeer grote Subversion-repository's kunnen grotere waarden nodig zijn
klonen/halen binnen een redelijke tijd te voltooien. Maar te hoge waarden kunnen leiden tot
hoger geheugengebruik en time-outs van verzoeken.

klonen
Runs init en halen. Er wordt automatisch een map aangemaakt op basis van de basisnaam van
de URL die eraan wordt doorgegeven; of als een tweede argument wordt doorgegeven; er wordt een map aangemaakt
en daarbinnen werken. Zij aanvaardt alle argumenten dat de init en halen commando's
aanvaarden; met uitzondering van --alles ophalen en --ouder. Nadat een repository is gekloond,
the halen commando kan revisies bijwerken zonder de werkboom te beïnvloeden;
en opnieuw baseren commando kan de werkboom bijwerken met de nieuwste versie
veranderingen.

--preserve-lege-map
Maak voor elke lege map een plaatshouderbestand in de lokale Git-repository
opgehaald uit Subversion. Dit geldt ook voor mappen die leeg raken door verwijdering
alle vermeldingen in de Subversion-repository (maar niet de directory zelf). De
tijdelijke aanduiding-bestanden worden ook bijgehouden en verwijderd wanneer ze niet langer nodig zijn.

--placeholder-bestandsnaam=
Stel de naam in van tijdelijke aanduiding-bestanden gemaakt door --preserve-empty-dirs. Standaard:
".gitignore"

opnieuw baseren
Hiermee worden revisies opgehaald van de SVN-ouder van de huidige HEAD en wordt de huidige opnieuw gebaseerd
(niet toegewijd aan SVN) werken dit tegen.

Dit werkt op dezelfde manier als svn update of git trek behalve dat het de lineaire geschiedenis bewaart
with git opnieuw baseren in plaats van git samensmelten voor het gemak waarmee u zich kunt verbinden git svn.

Dit accepteert alle opties die git svn halen en git opnieuw baseren aanvaarden. Echter,
--alles ophalen haalt alleen de huidige [svn-remote] op, en niet alle [svn-remote]
definities.

Like git opnieuw baseren; dit vereist dat de werkende boom schoon is en geen vrije verplichtingen heeft
veranderingen.

Hierdoor wordt de rev_map indien nodig automatisch bijgewerkt (zie $GIT_DIR/svn/**/.rev_map.* in
het gedeelte BESTANDEN hieronder voor meer informatie).

-l, --lokaal
Niet op afstand ophalen; alleen rennen git opnieuw baseren tegen de laatst opgehaalde commit van
de stroomopwaartse SVN.

vastleggen
Leg elke diff van de huidige branch rechtstreeks vast in de SVN-repository, en vervolgens
rebase of reset (afhankelijk van of er al dan niet een verschil is tussen SVN en head).
Dit zal een revisie in SVN creëren voor elke commit in Git.

Wanneer een optionele Git-branchnaam (of een Git commit-objectnaam) wordt gespecificeerd als een
argument werkt het subcommando op de opgegeven vertakking, niet op de huidige vertakking.

gebruik van vastleggen heeft de voorkeur set-boom (Hieronder).

--geen-rebase
Na het committen mag je niet rebaseen of resetten.

--commit-url
Houd u aan deze SVN-URL (het volledige pad). Dit is bedoeld om bestaande mogelijk te maken git svn
repository's gemaakt met één transportmethode (bijvoorbeeld svn:// of http:// for
anoniem lezen) om opnieuw te gebruiken als een gebruiker later toegang krijgt tot een alternatief
transportmethode (bijvoorbeeld svn+ssh:// of https://) voor commit.

configuratiesleutel: svn-remote. .commiturl
configuratiesleutel: svn.commiturl (overschrijft alle svn-remote. .commiturl-opties)

Merk op dat de SVN-URL van de commiturl-configuratiesleutel de SVN-vertakking bevat. als jij
wil liever de commit-URL instellen voor een volledig gebruik van de SVN-repository
svn-afstandsbediening. .pushrl in plaats daarvan.

Het gebruik van deze optie voor andere doeleinden (niet vragen) wordt sterk afgeraden.

--mergeinfo=
Voeg de gegeven merge-informatie toe tijdens de dcommit (bijv
--mergeinfo="/branches/foo:1-10"). Alle svn-serverversies kunnen dit opslaan
informatie (als eigenschap), en svn-clients vanaf versie 1.5 kunnen maken
gebruik ervan. Gebruik één spatie om samenvoeggegevens van meerdere vertakkingen op te geven
teken tussen de takken (--mergeinfo="/branches/foo:1-10
/takken/staaf:3,5-6,8")

configuratiesleutel: svn.pushmergeinfo

Deze optie zorgt ervoor dat git-svn probeert om automatisch het
svn:mergeinfo in de SVN-repository indien mogelijk. Momenteel kan dit
kan alleen worden gedaan als dcommitting niet-snel vooruit wordt samengevoegd waarbij alle ouders behalve de
De eerste zijn al in SVN geduwd.

--interactief
Vraag de gebruiker om te bevestigen dat er daadwerkelijk een patchset naar SVN moet worden verzonden. Voor elk
patch, men kan antwoorden met "ja" (accepteer deze patch), "nee" (gooi deze patch weg), "alles"
(accepteer alle patches) of "stop".

git svn vastleggen keert onmiddellijk terug als het antwoord "nee" of "stop" is, zonder
iets aan SVN toezeggen.

tak
Maak een vertakking in de SVN-repository.

-m, --bericht
Maakt het mogelijk om het commit-bericht te specificeren.

-t, --tag
Maak een tag door de tags_subdir te gebruiken in plaats van de opgegeven branches_subdir
tijdens git svn init.

-D , --bestemming=
Als er meer dan één --branches (of --tags) optie is gegeven aan de init or klonen
commando, moet u de locatie opgeven van de vertakking (of tag) die u wilt maken
in de SVN-repository. specificeert welk pad moet worden gebruikt om de vertakking te maken of
tag en moet overeenkomen met het patroon aan de linkerkant van een van de geconfigureerde
takken of tags refspecs. Je kunt deze refspecs zien met de commando's

git config --get-all svn-remote. .takken
git config --get-all svn-remote. .tags

waar is de naam van de SVN-repository zoals gespecificeerd door de optie -R
init (of standaard "svn").

--gebruikersnaam
Geef de SVN-gebruikersnaam op waarmee de commit moet worden uitgevoerd. Deze optie overschrijft de
gebruikersnaam configuratie-eigenschap.

--commit-url
Gebruik de opgegeven URL om verbinding te maken met de doel-Subversion-repository. Dit is
handig in gevallen waarin de bron-SVN-repository alleen-lezen is. Deze optie
overschrijft de configuratie-eigenschap commiturl.

git config --get-all svn-remote. .commiturl

--ouders
Maak bovenliggende mappen. Deze parameter is gelijk aan de parameter --parents on
svn cp-opdrachten en is handig voor niet-standaard repository-indelingen.

label
Maak een tag in de SVN-repository. Dit is een afkorting voor tak -t.

inloggen
Dit zou het gemakkelijk moeten maken om svn-logberichten op te zoeken waar svn-gebruikers naar verwijzen
-r/--revisienummers.

De volgende functionaliteiten uit 'svn log' worden ondersteund:

-R [: ], --revisie= [: ]
wordt ondersteund, niet-numerieke argumenten zijn dat niet: HEAD, NEXT, BASE, PREV, enz...

-v, --uitgebreid
het is niet volledig compatibel met de uitvoer --verbose in svn log, maar
redelijk dichtbij.

--limiet=
is NIET hetzelfde als --max-count, telt samengevoegde/uitgesloten commits niet

--toenemend
ondersteund

Nieuwe functies:

--show-commit
toont ook de Git commit sha1

--een lijn
onze versie van --pretty=oneline

Note
SVN zelf slaat alleen tijden op in UTC en verder niets. De reguliere svn-client
converteert de UTC-tijd naar de lokale tijd (of gebaseerd op de TZ=-omgeving). Dit
commando heeft hetzelfde gedrag.
Alle andere argumenten worden rechtstreeks doorgegeven aan git inloggen

schuld
Laat elke regel van een bestand zien welke revisie en auteur het laatst heeft gewijzigd. De opbrengst hiervan
modus is standaard formaatcompatibel met de uitvoer van 'svn blaam'. Zoals de SVN
schuldopdracht, lokale niet-vastgelegde wijzigingen in de werkboom worden genegeerd; de versie
van het bestand in de HEAD-revisie wordt geannoteerd. Onbekende argumenten worden direct doorgegeven
naar git schuld.

--git-formaat
Produceer uitvoer in hetzelfde formaat als git schuld, maar met SVN-revisienummers
in plaats van Git commit-hashes. In deze modus worden wijzigingen doorgevoerd die nog niet zijn vastgelegd
SVN (inclusief lokale bewerkingen van werkkopieën) worden weergegeven als revisie 0.

vind-rev
Bij opgave van een SVN-revisienummer van het formulier rN, retourneert de overeenkomstige Git-commit
hash (dit kan optioneel gevolgd worden door een tree-achtig om aan te geven welke tak moet zijn
gezocht). Wanneer een boomstructuur wordt gegeven, wordt het overeenkomstige SVN-revisienummer geretourneerd.

-B, --vóór
Vereist geen exacte overeenkomst als u een SVN-revisie krijgt, maar zoek in plaats daarvan de commit
overeenkomend met de status van de SVN-repository (op de huidige vertakking) op de
gespecificeerde revisie.

-A, --na
Geen exacte match vereisen als u een SVN-revisie krijgt; als er geen exacte is
match retourneert de dichtstbijzijnde match die vooruit zoekt in de geschiedenis.

set-boom
Je zou moeten overwegen om te gebruiken vastleggen in plaats van dit commando. Commit gespecificeerde commit of
boomobjecten naar SVN. Dit is afhankelijk van het feit dat uw geïmporteerde ophaalgegevens up-to-date zijn. Dit
doet absoluut geen pogingen om patching uit te voeren wanneer hij zich aan SVN verbindt, het is eenvoudigweg
overschrijft bestanden met de bestanden die zijn opgegeven in de boomstructuur of commit. Van elke samenvoeging wordt aangenomen dat dit het geval is
onafhankelijk van elkaar hebben plaatsgevonden git svn functies.

creëren-negeren
Vindt recursief de eigenschap svn:ignore in mappen en creëert overeenkomsten
.gitignore-bestanden. De resulterende bestanden zijn geënsceneerd om te worden vastgelegd, maar zijn dat niet
betrokken. Gebruik -r/--revision om naar een specifieke revisie te verwijzen.

toon-negeer
Zoekt en vermeldt recursief de eigenschap svn:ignore in mappen. De uitvoer is
geschikt om toe te voegen aan het bestand $GIT_DIR/info/exclude.

mkdirs
Pogingen om lege mappen opnieuw te maken die kern-Git niet kan volgen op basis van informatie
in $GIT_DIR/svn/ /unhandled.log-bestanden. Lege mappen worden automatisch verwijderd
opnieuw gemaakt bij gebruik van "git svn clone" en "git svn rebase", dus "mkdirs" is bedoeld voor
gebruik na commando's zoals "git checkout" of "git reset". (Zie de
svn-afstandsbediening. .automkdirs configuratiebestand voor meer informatie.)

commit-verschil
Voert de diff van twee boomargumenten vanaf de opdrachtregel door. Dit commando wel
vertrouw er niet op dat je in een door git svn geïnitieerde repository bent. Voor deze opdracht zijn er drie nodig
argumenten, (a) de oorspronkelijke boom waartegen moet worden gedifferentieerd, (b) het nieuwe boomresultaat, (c) de URL
van de doel-Subversion-repository. Het laatste argument (URL) kan worden weggelaten als u
werken vanuit een git svn-aware repository (die is geïnitieerd met git svn). De
-R Hiervoor is een optie vereist.

info
Toont informatie over een bestand of map, vergelijkbaar met wat 'svn info' biedt. Doet
ondersteunt momenteel geen -r/--revision-argument. Gebruik de --url optie om alleen uit te voeren
de waarde van de URL: veld.

proplijst
Geeft een overzicht van de eigenschappen die zijn opgeslagen in de Subversion-repository over een bepaald bestand of
map. Gebruik -r/--revision om naar een specifieke Subversion-revisie te verwijzen.

propageren
Haalt de Subversion-eigenschap op die als eerste argument voor een bestand is opgegeven. Een specifiek
revisie kan worden opgegeven met -r/--revision.

show-externen
Toont de externe Subversion-bronnen. Gebruik -r/--revision om een ​​specifieke revisie op te geven.

gc
Comprimeer $GIT_DIR/svn/ /unhandled.log-bestanden en verwijder deze
$GIT_DIR/svn/ /index-bestanden.

opnieuw in te stellen
Maakt de effecten ongedaan halen terug naar de opgegeven revisie. Hierdoor kunt u dat doen
re-halen een SVN-revisie. Normaal gesproken mag de inhoud van een SVN-revisie nooit veranderen
en opnieuw in te stellen zou niet nodig moeten zijn. Als de SVN-machtigingen echter veranderen, of als u wijzigingen aanbrengt
uw --ignore-paths optie, a halen kan mislukken met "niet gevonden in commit" (bestand niet
eerder zichtbaar) of "checksum komt niet overeen" (een wijziging gemist). Als het probleem
bestand kan niet voor altijd worden genegeerd (met --ignore-paths), de enige manier om de repository te repareren
is het gebruik opnieuw in te stellen.

Alleen de rev_map en refs/remotes/git-svn zijn veranderd (zie $GIT_DIR/svn/**/.rev_map.*
in het gedeelte BESTANDEN hieronder voor meer informatie). Volgen opnieuw in te stellen met een halen en git opnieuw in te stellen
or git opnieuw baseren om lokale takken naar de nieuwe boom te verplaatsen.

-R , --revisie=
Geef de meest recente revisie op die u wilt behouden. Alle latere herzieningen worden verworpen.

-p, --ouder
Gooi ook de opgegeven revisie weg, maar behoud in plaats daarvan de dichtstbijzijnde ouder.

Voorbeeld:
Stel dat u lokale wijzigingen heeft in "master", maar dat u "r2" opnieuw moet ophalen.

r1---r2---r3 afstandsbedieningen/git-svn

A---B meester

Los het probleem met negeerpaden of SVN-machtigingen op dat ervoor zorgde dat "r2" onvolledig was
in de eerste plaats. Dan:

git svn-reset -r2 -p
git svn ophalen

r1---r2'--r3' afstandsbedieningen/git-svn

r2---r3---A---B meester

Fixeer vervolgens "master" met git opnieuw baseren. Gebruik niet git samensmelten anders zal jouw geschiedenis dat niet doen
verenigbaar zijn met een toekomst vastleggen!

git rebase --onto remotes/git-svn A^ master

r1---r2'--r3' afstandsbedieningen/git-svn

A'--B' meester

OPTIES

--shared[=(false|true|umask|groep|alle|wereld|iedereen)], --template=
Alleen gebruikt met de init commando. Deze worden rechtstreeks doorgegeven aan git init.

-R , --revisie
Gebruikt met de halen opdracht.

Hierdoor kunnen revisiebereiken voor gedeeltelijke/gecauteriseerde geschiedenis worden ondersteund. $NUMMER,
$NUMBER1:$NUMBER2 (numerieke bereiken), $NUMBER:HEAD en BASE:$NUMBER worden allemaal ondersteund.

Hierdoor kunt u gedeeltelijke spiegels maken tijdens het ophalen; maar is dat over het algemeen niet
aanbevolen omdat de geschiedenis wordt overgeslagen en verloren gaat.

-, --standaard
Alleen gebruikt met de set-boom opdracht.

Lees een lijst met commits van stdin en commit ze in omgekeerde volgorde. Alleen de leidende
sha1 wordt vanaf elke regel gelezen, dus git rev-lijst --mooi=één regel uitgang kan worden gebruikt.

--rmdir
Alleen gebruikt met de vastleggen, set-boom en commit-verschil commando's.

Verwijder mappen uit de SVN-boom als er geen bestanden achterblijven. SVN kan dat wel
versie lege mappen, en deze worden niet standaard verwijderd als er geen bestanden zijn
in hen achtergelaten. Git kan geen versies van lege mappen maken. Als u deze vlag inschakelt, wordt de
committeren aan SVN en handelen als Git.

configuratiesleutel: svn.rmdir

-e, --edit
Alleen gebruikt met de vastleggen, set-boom en commit-verschil commando's.

Bewerk het commit-bericht voordat u zich aan SVN commit. Voor objecten is dit standaard uitgeschakeld
dat zijn commits, en wordt gedwongen bij het committen van boomobjecten.

configuratiesleutel: svn.edit

-l , --vind-kopieën-moeilijker
Alleen gebruikt met de vastleggen, set-boom en commit-verschil commando's.

Ze worden beide rechtstreeks doorgegeven git diff-boom; zien git-diff-boom(1) voor meer
informatie.

configuratiesleutel: svn.l
configuratiesleutel: svn.findcopiesharder

-A , --auteurs-file=
Syntaxis is compatibel met het bestand dat wordt gebruikt door git cvimport:

loginnaam = Joe Gebruikergebruiker@voorbeeld.com>

Als deze optie is opgegeven en git svn komt een SVN-committernaam tegen die dat niet doet
bestaan ​​in het auteursbestand, git svn zal de operatie afbreken. De gebruiker zal dan wel moeten
voeg de juiste vermelding toe. De vorige opnieuw uitvoeren git svn commando na de
auteursbestand wordt gewijzigd om de werking voort te zetten.

configuratiesleutel: svn.authorsfile

--auteurs-prog=
Als deze optie is opgegeven, wordt voor elke SVN-committernaam die niet bestaat in de
auteursbestand, wordt het opgegeven bestand uitgevoerd met de naam van de committer als eerste
argument. Er wordt verwacht dat het programma een enkele regel retourneert in de vorm "Naam ",
die zal worden behandeld alsof deze is opgenomen in het auteursbestand.

-q, --stil
Merk git svn minder uitgebreid. Geef een tweede keer op om het nog minder uitgebreid te maken.

-m, --samenvoegen, -s , --strategie= , -p, --preserve-samenvoegingen
Deze worden alleen gebruikt bij de vastleggen en opnieuw baseren commando's.

Direct doorgegeven aan git opnieuw baseren bij gebruik vastleggen indien git opnieuw in te stellen kan niet worden gebruikt (zie
vastleggen).

-n, --drooglopen
Deze kan gebruikt worden met de vastleggen, opnieuw baseren, tak en label commando's.

Voor vastleggen, druk de reeks Git-argumenten af ​​die zouden laten zien welke diffs dat zouden doen
zich inzetten voor SVN.

Voor opnieuw baseren, geef de lokale vertakking weer die is gekoppeld aan de upstream svn-repository
geassocieerd met de huidige branch en de URL van de svn-repository die zal worden opgehaald
van.

Voor tak en label, geef de URL's weer die zullen worden gebruikt voor het kopiëren bij het maken van het
tak of tag.

--use-log-auteur
Bij het ophalen van svn-commits in Git (als onderdeel van halen, opnieuw baserenof vastleggen
bewerkingen), zoekt u naar de eerste regel From: of Signed-off-by: in het logbericht en
gebruik dat als de auteursreeks.

--add-auteur-van
Wanneer je een commit maakt naar svn vanuit Git (als onderdeel van commit-verschil, set-boom or vastleggen
bewerkingen), als het bestaande logbericht nog geen Van: of bevat
Ondertekend door: regel, voeg een Van: regel toe, gebaseerd op de auteursreeks van de Git commit. Als
Als je dit gebruikt, zal --use-log-author voor iedereen een geldige auteursreeks ophalen
begaat.

ADVANCED OPTIES

-i , --ID kaart
Hiermee wordt GIT_SVN_ID ingesteld (in plaats van de omgeving te gebruiken). Hierdoor kan de gebruiker
overschrijf de standaard refname die moet worden opgehaald bij het bijhouden van een enkele URL. De inloggen en
vastleggen opdrachten vereisen deze schakelaar niet langer als argument.

-R , --svn-remote
Specificeer de [svn-remote " "] sectie te gebruiken, hierdoor zijn meerdere SVN's mogelijk
opslagplaatsen te volgen. Standaard: "svn"

--volg-ouder
Deze optie is alleen relevant als we branches volgen (met behulp van een van de repository
lay-outopties --trunk, --tags, --branches, --stdlayout). Probeer het voor elke gevolgde tak
om erachter te komen waar de revisie vandaan is gekopieerd, en stel een geschikte ouder in de eerste
Git commit voor de branch. Dit is vooral handig als we een directory bijhouden
die binnen de repository is verplaatst. Als deze functie is uitgeschakeld, wordt de
takken gemaakt door git svn zullen allemaal lineair zijn en geen enkele geschiedenis delen, wat betekent dat
er zal geen informatie zijn over waar vestigingen zijn afgesplitst of samengevoegd. Echter,
het volgen van een lange/ingewikkelde geschiedenis kan lang duren, dus schakel deze functie uit
kan het kloonproces versnellen. Deze functie is standaard ingeschakeld, gebruik
--no-follow-parent om het uit te schakelen.

configuratiesleutel: svn.followparent

CONFIG ALLEEN BESTAND OPTIES

svn.noMetadata, svn-remote. .noMetagegevens
Hiermee wordt de git-svn-id: regels aan het einde van elke commit.

Deze optie kan alleen worden gebruikt voor eenmalige importen als git svn zal niet kunnen ophalen
wederom zonder metadata. Bovendien, als u uw $GIT_DIR/svn/**/.rev_map.*
bestanden, git svn zullen ze niet kunnen herbouwen.

De git svn inloggen commando zal ook niet werken op repository's die dit gebruiken. Dit gebruiken
conflicteert met de gebruikSvmProps optie om (hopelijk) voor de hand liggende redenen.

Deze optie wordt NIET aanbevolen, omdat het hierdoor moeilijk wordt om oude referenties op te sporen
naar SVN-revisienummers in bestaande documentatie, bugrapporten en archieven. als jij
zijn van plan om uiteindelijk van SVN naar Git te migreren en zijn er zeker van dat ze de SVN-geschiedenis zullen laten vallen,
overwegen git-filter-branch(1) in plaats daarvan. filter-branch maakt ook het opnieuw formatteren van
metadata voor leesgemak en herschrijven van auteursinformatie voor niet-"svn.authorsFile"
gebruikers.

svn.useSvmProps, svn-remote. .useSvmProps
Dit staat toe git svn om repository-URL's en UUID's opnieuw toe te wijzen van spiegels die zijn gemaakt met behulp van
SVN::Mirror (of svk) voor metagegevens.

Als een SVN-revisie de eigenschap "svm:headrev" heeft, is het waarschijnlijk dat de revisie dat was
gemaakt door SVN::Mirror (ook gebruikt door SVK). De eigenschap bevat een repository UUID en
een herziening. We willen het laten lijken alsof we de originele URL spiegelen, dus
introduceer een helperfunctie die de oorspronkelijke identiteits-URL en UUID retourneert, en gebruik
dit bij het genereren van metadata in commit-berichten.

svn.useSvnsyncProps, svn-remote. .useSvnsyncprops
Vergelijkbaar met de optie useSvmProps; dit is voor gebruikers van de svnsync(1) bevel
gedistribueerd met SVN 1.4.x en hoger.

svn-afstandsbediening. .rewriteRoot
Hierdoor kunnen gebruikers opslagplaatsen maken op basis van alternatieve URL's. Bijvoorbeeld, een
beheerder zou kunnen uitvoeren git svn op de server lokaal (toegang via file://) maar wens
om de repository te distribueren met een openbare http:// of svn:// URL in de metadata
gebruikers ervan zullen de openbare URL zien.

svn-afstandsbediening. .rewriteUUID
Vergelijkbaar met de optie useSvmProps; dit is voor gebruikers die de UUID opnieuw moeten toewijzen
handmatig. Dit kan handig zijn in situaties waarin de oorspronkelijke UUID niet beschikbaar is
via useSvmProps of useSvnsyncProps.

svn-afstandsbediening. .duw
Vergelijkbaar met die van Git op afstand. .duw, deze sleutel is ontworpen om te worden gebruikt in gevallen waarin
url verwijst naar een SVN-repository via een alleen-lezen transport, om een ​​alternatief te bieden
lees/schrijf-transport. Er wordt aangenomen dat beide sleutels naar dezelfde repository verwijzen.
Anders commiturl, pushurl is een basispad. Als een van beide commiturl or pushurl zou kunnen
gebruikt, commiturl heeft voorrang.

svn.brokenSymlinkWorkaround
Hierdoor worden mogelijk dure controles uitgeschakeld om gebroken symlinks te omzeilen waarin is ingecheckt
SVN door gebroken klanten. Stel deze optie in op "false" als u een SVN-repository volgt
veel lege blobs die geen symlinks zijn. Deze optie kan tijdens het wijzigen worden gewijzigd git svn is
actief en wordt van kracht op de volgende opgehaalde revisie. Indien uitgeschakeld, git svn veronderstelt dit
optie om ‘waar’ te zijn.

svn.padnaamcodering
Dit instrueert git svn om padnamen te hercoderen naar een bepaalde codering. Het kan gebruikt worden door
Windows-gebruikers en door degenen die in niet-UTF8-landinstellingen werken om beschadigde bestandsnamen te voorkomen
met niet-ASCII-tekens. Geldige coderingen worden ondersteund door Perl's Encode
module.

svn-afstandsbediening. .automkdirs
Normaal gesproken proberen de commando's "git svn clone" en "git svn rebase" lege
mappen die zich in de Subversion-repository bevinden. Als deze optie is ingesteld op 'false',
dan zullen er alleen lege mappen worden aangemaakt als het commando "git svn mkdirs" wordt uitgevoerd
uitdrukkelijk. Indien uitgeschakeld, git svn gaat ervan uit dat deze optie "waar" is.

Sinds de opties noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps en useSvmProps
ze hebben allemaal invloed op de metagegevens die worden gegenereerd en gebruikt door git svn; ze Dan moet je worden ingesteld in de
configuratiebestand voordat enige geschiedenis wordt geïmporteerd en deze instellingen mogen dat nooit zijn
gewijzigd zodra ze zijn ingesteld.

Bovendien kan per svn-remote-sectie slechts één van deze opties worden gebruikt, omdat ze
van invloed op de git-svn-id: metadataregel, behalve rewriteRoot en rewriteUUID die dat wel kunnen zijn
samen gebruikt.

BASIC Voorbeelden

Het volgen van en bijdragen aan de stam van een door Subversion beheerd project (tags negeren en
takken):

# Een repository klonen (zoals git clone):
git svn-kloon http://svn.example.com/project/trunk
# Voer de nieuw gekloonde map in:
cd-kofferbak
# Je zou in de master branch moeten zitten, controleer nogmaals met 'git branch'
git tak
# Doe wat werk en commit je lokaal aan Git:
git begaan ...
# Er is iets toegewijd aan SVN, rebase uw lokale wijzigingen tegen de
# laatste wijzigingen in SVN:
git svn-rebase
# Leg nu uw wijzigingen (die eerder met Git zijn vastgelegd) vast in SVN,
# en het automatisch bijwerken van uw werkende HEAD:
git svn dcommit
# Voeg svn:ignore-instellingen toe aan het standaard Git-uitsluitingsbestand:
git svn show-ignore >> .git/info/exclude

Het volgen van en bijdragen aan een volledig door Subversion beheerd project (compleet met een trunk,
tags en takken):

# Kloon een repository met standaard SVN-mapindeling (zoals git clone):
git svn-kloon http://svn.example.com/project --stdlayout --voorvoegsel svn/
# Of, als de repository een niet-standaard mapindeling gebruikt:
git svn-kloon http://svn.example.com/project -T tr -b branch -t tag --voorvoegsel svn/
# Bekijk alle takken en tags die je hebt gekloond:
git tak -r
# Maak een nieuwe vestiging in SVN
git svn branch waldo
# Reset uw master naar trunk (of een andere tak, ter vervanging van 'trunk'
# met de juiste naam):
git reset --hard svn/trunk
# U kunt zich slechts aan één branch/tag/trunk tegelijk binden. Het gebruik
# van dcommit/rebase/show-ignore moet hetzelfde zijn als hierboven.

De eerste git svn klonen kan behoorlijk tijdrovend zijn (vooral voor grote Subversion
opslagplaatsen). Als meerdere mensen (of één persoon met meerdere machines) er gebruik van willen maken git
svn om met dezelfde Subversion-repository te communiceren, kunt u de initiaal uitvoeren git svn klonen
naar een repository op een server en laat elke persoon die repository klonen git klonen:

# Voer de eerste import uit op een server
ssh server "cd /pub && git svn kloon http://svn.example.com/project [opties...]"
# Lokaal klonen - zorg ervoor dat de refs/remotes/space overeenkomt met de server
mkdir-project
cd-project
git init
git remote voeg origin server:/pub/project toe
git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git ophalen
# Voorkom ophalen/ophalen van externe Git-server in de toekomst,
# we willen git svn alleen gebruiken voor toekomstige updates
git config --remove-sectie remote.origin
# Maak een lokale vertakking van een van de zojuist opgehaalde vertakkingen
git checkout -b master FETCH_HEAD
# Initialiseer 'git svn' lokaal (zorg ervoor dat u dezelfde URL en
# --stdlayout/-T/-b/-t/--prefix opties zoals gebruikt op de server)
git svn init http://svn.example.com/project [opties...]
# Haal de laatste wijzigingen uit Subversion
git svn-rebase

REBASIS VS. TREKKEN/SAMENVOEGEN

Liever gebruiken git svn opnieuw baseren or git opnieuw baseren, liever dan git trek or git samensmelten naar
synchroniseer niet-geïntegreerde commits met a git svn tak. Als u dit doet, blijft de geschiedenis van
niet-geïntegreerde commits lineair met betrekking tot de upstream SVN-repository en staan ​​het gebruik toe
van de voorkeur git svn vastleggen subcommando om niet-geïntegreerde commits terug naar SVN te pushen.

Oorspronkelijk, git svn aanbevolen dat ontwikkelaars de git svn tak.
Dit kwam omdat de auteur de voorkeur gaf aan git svn set-tree B om een ​​enkele head te committen in plaats van
de git svn set-tree A..B notatie om meerdere commits te committen. Gebruik van git trek or git
samensmelten met git svn set-tree A..B zal ervoor zorgen dat de niet-lineaire geschiedenis afgevlakt wordt wanneer
committen in SVN en dit kan ertoe leiden dat merge commits onverwachts de vorige ongedaan maken
zet zich in bij SVN.

MERGE TRACKING

Terwijl git svn kan de kopieergeschiedenis (inclusief vertakkingen en tags) voor repository's volgen
door een standaard lay-out aan te nemen, kan het nog niet de samenvoeggeschiedenis weergeven die binnen git plaatsvond
back-upstream naar SVN-gebruikers. Daarom wordt geadviseerd dat gebruikers de geschiedenis zo lineair mogelijk houden
mogelijk binnen Git om de compatibiliteit met SVN te vergemakkelijken (zie de sectie CAVEATS hieronder).

VERWERKING BESTELLING OF SVN BRANCHES

If git svn is geconfigureerd om branches op te halen (en --follow-branches is van kracht), het
creëert soms meerdere Git-vertakkingen voor één SVN-vertakking, waarbij de extra vertakkingen aanwezig zijn
hebben namen van het formulier filiaalnaam@nnn (met nnn een SVN-revisienummer). Deze extra
er worden takken gemaakt als git svn kan geen bovenliggende commit vinden voor de eerste commit in een SVN
branch, om de branch te verbinden met de geschiedenis van de andere branches.

Normaal gesproken bestaat de eerste commit in een SVN-vertakking uit een kopieerbewerking. git svn wil
lees deze commit om de SVN-revisie op te halen waaruit de branch is gemaakt. Het zal het dan proberen
zoek de Git-commit die overeenkomt met deze SVN-revisie, en gebruik die als ouder van
de tak. Het is echter mogelijk dat er geen geschikte Git-commit is om als
ouder. Dit zal onder meer gebeuren als de SVN-vestiging een kopie is van een revisie
dat werd niet gehaald git svn (bijvoorbeeld omdat het een oude revisie is waarmee is overgeslagen
--herziening), of als er in SVN een map is gekopieerd die niet wordt bijgehouden door git svn (zoals een
vertakking die helemaal niet wordt gevolgd, of een submap van een gevolgde vertakking). In deze gevallen,
git svn zal nog steeds een Git branch aanmaken, maar in plaats van een bestaande Git commit als
ouder van de vertakking, zal het de SVN-geschiedenis lezen van de directory waarin de vertakking is gekopieerd
van en maak geschikte Git-commits. Dit wordt aangegeven door de melding ‘Initializing
ouder: ".

Bovendien zal het een speciale vertakking creëren met de naam @, Waar
is het SVN-revisienummer waaruit het filiaal is gekopieerd. Deze tak zal
wijs naar de nieuw gemaakte bovenliggende commit van de vertakking. Als in SVN de vestiging is verwijderd
en later opnieuw gemaakt vanuit een andere versie, zullen er meerdere van dergelijke vertakkingen zijn met een
@.

Houd er rekening mee dat dit kan betekenen dat er meerdere Git-commits worden gemaakt voor een enkele SVN-revisie.

Een voorbeeld: in een SVN-repository met een standaard trunk/tags/branches-indeling, een directory
trunk/sub wordt aangemaakt in r.100. In r.200 wordt trunk/sub vertakt door deze te kopiëren naar branches/.
git svn klonen -s zal dan een filiaal aanmaken beneden. Het zal ook nieuwe Git-commits creëren voor
r.100 tot en met r.199 en gebruik deze als de geschiedenis van de vertakking beneden. Er zullen dus twee Git
commit voor elke revisie van r.100 tot en met r.199 (één bevat trunk/, één bevat
hoofdlijn/sub/). Ten slotte zal er een filiaal worden gemaakt minder dan 200 verwijzend naar de nieuwe bovenliggende commit van
tak beneden (dwz de commit voor r.200 en trunk/sub/).

WAARSCHUWINGEN

Omwille van de eenvoud en de samenwerking met Subversion wordt het aanbevolen om dit allemaal te doen
git svn gebruikers klonen, halen en dcommiteren rechtstreeks vanaf de SVN-server en vermijden alles git
klonen/trek/samensmelten/duwen bewerkingen tussen Git-repository's en branches. De aanbevolen
methode voor het uitwisselen van code tussen Git-vestigingen en gebruikers is git formaat-patch en git am,
of gewoon 'dcommit'en naar de SVN-repository.

Hardlopen git samensmelten or git trek wordt NIET aanbevolen voor een vestiging waar u naartoe wilt vastleggen vanaf
omdat Subversion-gebruikers de door u gemaakte samenvoegingen niet kunnen zien. Bovendien, als u samenvoegt of
pull uit een Git-branch die een spiegel is van een SVN-branch, vastleggen kan het verkeerde begaan
tak.

Als u toch samenvoegt, houd dan rekening met de volgende regel: git svn vastleggen zal proberen er bovenop te komen
de SVN-commit genoemd in

git log --grep=^git-svn-id: --first-parent -1

Je Dan moet je Zorg er daarom voor dat de meest recente commit van de branch waar je naartoe wilt committen
is de eerste moedermaatschappij van de fusie. Anders zal er chaos ontstaan, vooral in het eerste geval
parent is een oudere commit op dezelfde SVN-branch.

git klonen kloont geen branches onder de refs/remotes/hiërarchie of wat dan ook git svn
metagegevens of configuratie. Dus repository's gemaakt en beheerd met behulp van git svn zou gebruiken
rsync voor klonen, als klonen überhaupt moet gebeuren.

Sinds vastleggen gebruikt rebase intern, elke Git vertakt je git duwen voor vastleggen on
vereist het forceren van een overschrijving van de bestaande ref op de externe repository. Dit is
algemeen als slechte praktijk beschouwd, zie de git-push(1) documentatie voor details.

Gebruik niet de optie --amend van git-commit(1) op een wijziging die u al heeft vastgelegd. Het
Het wordt als een slechte gewoonte beschouwd om commits te wijzigen die je al naar een externe repository hebt gepusht
voor andere gebruikers, en dcommit met SVN is daarmee analoog.

Bij het klonen van een SVN-repository, als geen van de opties voor het beschrijven van de repository aanwezig is
layout wordt gebruikt (--trunk, --tags, --branches, --stdlayout), git svn klonen zal een Git maken
repository met volledig lineaire geschiedenis, waarbij vertakkingen en tags afzonderlijk verschijnen
mappen in de werkkopie. Hoewel dit de gemakkelijkste manier is om een ​​kopie van een compleet exemplaar te krijgen
repository, voor projecten met veel vertakkingen zal dit vaak tot een werkkopie leiden
groter dan alleen de kofferbak. Dus voor projecten die de standaard directorystructuur gebruiken
(trunk/takken/tags), het wordt aanbevolen om te klonen met de optie --stdlay-out. Als het project
gebruikt een niet-standaard structuur, en/of als er geen vertakkingen en tags nodig zijn, is dit het gemakkelijkst
om slechts één map te klonen (meestal trunk), zonder enige repository-indeling op te geven
opties. Als de volledige geschiedenis met vestigingen en tags vereist is, zijn de opties --kofferbak /
--takken / --labels moet gebruikt worden.

Als u meerdere --branches of --tags gebruikt, git svn verwerkt de naam niet automatisch
botsingen (bijvoorbeeld als twee takken van verschillende paden dezelfde naam hebben, of als a
branch en een tag hebben dezelfde naam). Gebruik in deze gevallen init om je Git in te stellen
repository dan, vóór uw eerste halen, bewerk het bestand $GIT_DIR/config zodat de
takken en tags zijn gekoppeld aan verschillende naamruimten. Bijvoorbeeld:

branches = stabiel/*:refs/remotes/svn/stable/*
branches = debug/*:refs/remotes/svn/debug/*

Gebruik git-svn online met behulp van onworks.net-services