Svenska â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-svn last updated in 2.52.0

NAMN

git-svn - Dubbelriktad operation mellan ett Subversion-kodförrÄd och Git

SYNOPSIS

git svn <kommando> [<flaggor>] [<argument>]

BESKRIVNING

git svn Àr en enkel kanal för ÀndringsuppsÀttningar mellan Subversion och Git. Den tillhandahÄller ett dubbelriktat flöde av Àndringar mellan ett Subversion- och ett Git-kodförrÄd.

git svn kan spÄra ett vanligt Subversion-kodförrÄd, genom att följa den vanliga layouten "trunk/branches/tags", med alternativet --stdlayout. Den kan ocksÄ följa grenar och taggar i vilken layout som helst med alternativen -T/-t/-b (se alternativ för init nedan, och Àven kommandot clone).

NÀr ett Subversion-kodförrÄd har spÄrats (med nÄgon av ovanstÄende metoder) kan Git-kodförrÄdet uppdateras frÄn Subversion med kommandot fetch och Subversion uppdateras frÄn Git med kommandot dcommit.

KOMMANDON

init

Initierar ett tomt Git-kodförrÄd med ytterligare metadatakataloger för git svn. Subversion-URL:en kan anges som ett kommandoradsargument eller som fullstÀndiga URL-argument till -T/-t/-b. Valfritt kan mÄlkatalogen som ska anvÀndas anges som ett andra argument. Normalt initierar detta kommando den aktuella katalogen.

-T<stam-underkatalog>
--trunk=<stam-underkatalog>
-t<taggar-underkatalog>
--tags=<taggar-underkatalog>
-b<grenar-underkatalog>
--branches=<grenar-underkatalog>
-s
--stdlayout

Dessa Àr valfria kommandoradsalternativ för init. Var och en av dessa flaggor kan peka pÄ en relativ sökvÀg till kodförrÄdet (--tags=project/tags) eller en fullstÀndig url (--tags=https://foo.org/project/tags). Du kan ange mer Àn ett --tags- och/eller --branches-alternativ, ifall ditt Subversion-kodförrÄd placerar taggar eller grenar under flera sökvÀgar. Alternativet --stdlayout Àr ett förkortat sÀtt att stÀlla in trunk,tags,branches som relativa sökvÀgar, vilket Àr Subversions standardvÀrde. Om nÄgot av de andra alternativen ocksÄ anges har de företrÀde.

--no-metadata

StÀll in alternativet noMetadata i konfigurationsfilen [svn-remote]. Det hÀr alternativet rekommenderas inte, lÀs avsnittet svn.noMetadata pÄ den hÀr manualsidan innan du anvÀnder det.

--use-svm-props

StÀll in useSvmProps alternativet i [svn-remote] konfigurationsfilen.

--use-svnsync-props

StÀll in useSvnsyncProps alternativet i [svn-remote] konfigurationsfilen.

--rewrite-root=<URL>

StÀll in rewriteRoot alternativet i [svn-remote] konfigurationsfilen.

--rewrite-uuid=<UUID>

StÀll in rewriteUUID alternativet i [svn-remote] konfigurationsfilen.

--username=<anvÀndare>

För transporter som SVN hanterar autentisering för (http, https och vanlig svn), ange anvÀndarnamnet. För andra transporter (t.ex. svn+ssh://) mÄste du inkludera anvÀndarnamnet i URL:en, t.ex. svn+ssh://foo@svn.bar.com/project

--prefix=<prefix>

Det hÀr gör det möjligt att ange ett prefix som lÀggs till före namnen pÄ fjÀrrar om trunk/branches/tags anges. Prefixet inkluderar inte automatiskt ett avslutande snedstreck, sÄ se till att inkludera ett i argumentet om det Àr vad du vill. Om --branches/-b anges mÄste prefixet inkludera ett avslutande snedstreck. Att ange ett prefix (med ett avslutande snedstreck) rekommenderas starkt i vilket fall som helst, eftersom dina SVN-spÄrningsreferenser dÄ kommer att finnas pÄ "refs/remotes/$prefix/", vilket Àr kompatibelt med Gits egen layout för fjÀrrspÄrningsreferenser (refs/remotes/$remote/). Att ange ett prefix Àr ocksÄ anvÀndbart om du vill spÄra flera projekt som delar ett gemensamt kodförrÄd. Som standard Àr prefixet satt till origin/.

Note
 Före Git v2.0 var standardprefixet "" (inget prefix). Detta innebar att SVN-spÄrningsreferenser placerades vid "refs/remotes/*", vilket Àr inkompatibelt med hur Gits egna fjÀrrspÄrningsreferenser Àr organiserade. Om du fortfarande vill ha den gamla standardprefixen kan du fÄ den genom att skicka --prefix "" pÄ kommandoraden (--prefix="" kanske inte fungerar om din Perls Getopt::Long Àr < v2.37).
--ignore-refs=<regex>

NÀr det skickas till init eller clone kommer detta reguljÀra uttryck att bevaras som en konfigurationsnyckel. Se fetch för en beskrivning av --ignore-refs.

--ignore-paths=<regex>

NÀr det skickas till init eller clone kommer detta reguljÀra uttryck att bevaras som en konfigurationsnyckel. Se fetch för en beskrivning av --ignore-paths.

--include-paths=<regex>

NÀr det skickas till init eller clone kommer detta reguljÀra uttryck att bevaras som en konfigurationsnyckel. Se fetch för en beskrivning av --include-paths.

--no-minimize-url

NÀr man spÄrar flera kataloger (med hjÀlp av alternativen --stdlayout, --branches eller --tags) kommer git svn att försöka ansluta till roten (eller den högsta tillÄtna nivÄn) av Subversion-kodförrÄdet. Denna standardinstÀllning möjliggör bÀttre spÄrning av historik om hela projekt flyttas inom ett kodförrÄd, men kan orsaka problem pÄ kodförrÄd dÀr lÀsÄtkomstrestriktioner finns. Att skicka --no-minimize-url tillÄter git svn att acceptera URL:er som de Àr utan att försöka ansluta till en katalog pÄ högre nivÄ. Detta alternativ Àr avstÀngt som standard nÀr endast en URL/gren spÄras (det skulle inte göra nÄgon större nytta).

fetch

HĂ€mta revisioner som Ă€nnu inte hĂ€mtats frĂ„n Subversion-fjĂ€rren vi spĂ„rar. Namnet pĂ„ avsnittet [svn-remote "
​"] i filen $GIT_DIR/config kan anges som ett valfritt kommandoradsargument.

Det hÀr uppdaterar automatiskt rev_map om det behövs (se $GIT_DIR/svn/**/.rev_map.* i avsnittet FILER nedan för mer information).

--localtime

Lagra Git-incheckningstider i den lokala tidszonen i stÀllet för UTC. Detta gör att git log (Àven utan --date=local) visar samma tider som svn log skulle göra i den lokala tidszonen.

Det hÀr stör inte samverkan med Subversion-kodförrÄdet du klonade frÄn, men om du vill att ditt lokala Git-kodförrÄd ska kunna samverka med nÄgon annans lokala Git-kodförrÄd, anvÀnd antingen inte det hÀr alternativet eller sÄ bör ni bÄda anvÀnda det i samma lokala tidszon.

--parent

HÀmta endast frÄn SVN-förÀldern till den aktuella HEAD.

--ignore-refs=<regex>

Ignorera referenser för grenar eller taggar som matchar det reguljÀra uttrycket i Perl. En "negativ look-ahead-pÄstÄende" som ^refs/remotes/origin/(?!tags/wanted-tag|wanted-branch).*$ kan anvÀndas för att endast tillÄta vissa referenser.

konfigurationsnyckel: svn-remote.<namn>.ignore-refs

Om konfigurationsnyckeln ignore-refs Àr angiven och kommandoradsalternativet ocksÄ anges, kommer bÄda reguljÀra uttrycken att anvÀndas.

--ignore-paths=<regex>

Det hÀr gör det möjligt att ange ett reguljÀrt Perl-uttryck som gör att alla matchande sökvÀgar hoppas över frÄn utcheckningen frÄn SVN. Alternativet --ignore-paths ska matcha för varje fetch (inklusive automatiska hÀmtningar pÄ grund av clone, dcommit, rebase, etc.) pÄ ett givet kodförrÄd.

konfigurationsnyckel: svn-remote.<namn>.ignore-paths

Om konfigurationsnyckeln ignore-paths Àr instÀlld och kommandoradsalternativet ocksÄ anges, kommer bÄda reguljÀra uttrycken att anvÀndas.

Exempel:

Hoppa över katalogen "doc*" för varje hÀmtning 
--ignore-paths="^doc"
Hoppa över "grenar" och "taggar" i kataloger pÄ första nivÄn 
--ignore-paths="^[^/]+/(?:branches|tags)"
--include-paths=<regex>

Det hÀr gör det möjligt att ange ett reguljÀrt Perl-uttryck som gör att endast matchande sökvÀgar inkluderas vid utcheckning frÄn SVN. Alternativet --include-paths ska matcha för varje fetch (inklusive automatiska hÀmtningar pÄ grund av clone, dcommit, rebase, etc.) pÄ ett givet kodförrÄd. --ignore-paths har företrÀde framför --include-paths.

konfigurationsnyckel: svn-remote.<namn>.include-paths
--log-window-size=<n>

HÀmta <n> loggposter per begÀran vid skanning av Subversionshistorik. StandardvÀrdet Àr 100. För mycket stora Subversion-kodförrÄd kan större vÀrden behövas för att klona/hÀmta ska slutföras inom rimlig tid. Men alltför stora vÀrden kan leda till högre minnesanvÀndning och timeouts för begÀran.

clone

Kör init och fetch. Den skapar automatiskt en katalog baserat pÄ basnamnet pÄ URL:en som skickas till den; eller om ett andra argument skickas; skapar den en katalog och arbetar inom den. Den accepterar alla argument som kommandona init och fetch accepterar; med undantag för --fetch-all och --parent. Efter att ett kodförrÄd har klonats kommer kommandot fetch att kunna uppdatera revisioner utan att pÄverka arbetstrÀdet; och kommandot rebase kommer att kunna uppdatera arbetstrÀdet med de senaste Àndringarna.

--preserve-empty-dirs

Skapa en platshÄllarfil i det lokala Git-kodförrÄdet för varje tom katalog som hÀmtas frÄn Subversion. Detta inkluderar kataloger som blir tomma genom att ta bort alla poster i Subversion-kodförrÄdet (men inte sjÀlva katalogen). PlatshÄllarfilerna spÄras ocksÄ och tas bort nÀr de inte lÀngre behövs.

--placeholder-filename=<filnamn>

Ange namnet pÄ platshÄllarfiler som skapats av --preserve-empty-dirs. Standard: ".gitignore"

rebase

Det hÀr hÀmtar revisioner frÄn SVN-förÀldern till den aktuella HEAD-filen och ombaserar det nuvarande (ej incheckade till SVN) arbetet mot den.

Det hÀr fungerar pÄ liknande sÀtt som svn update eller git pull förutom att det bevarar linjÀr historik med git rebase i stÀllet för git merge för att förenkla dcommitning med git svn.

Det hÀr accepterar alla alternativ som git svn fetch och git rebase accepterar. Emellertid hÀmtar --fetch-all bara frÄn den aktuella [svn-remote], och inte alla [svn-remote] definitioner.

Liksom git rebase; detta krÀver att arbetstrÀdet Àr ren och inte har nÄgra oincheckade Àndringar.

Det hÀr uppdaterar automatiskt rev_map om det behövs (se $GIT_DIR/svn/**/.rev_map.* i avsnittet FILER nedan för mer information).

-l
--local

HÀmta inte pÄ distans; kör endast git rebase mot den senast hÀmtade incheckningen frÄn uppströms SVN.

dcommit

Checka in varje diff frÄn den aktuella grenen direkt till SVN-kodförrÄdet och ombasera eller ÄterstÀll sedan (beroende pÄ om det finns en diff mellan SVN och HEAD). Detta skapar en revision i SVN för varje incheckning i Git.

NÀr ett valfritt Git-grennamn (eller ett Git incheckningsobjektnamn) anges som ett argument, fungerar delkommandot pÄ den angivna grenen, inte pÄ den aktuella grenen.

AnvÀndning av dcommit Àr att föredra framför set-tree (nedan).

--no-rebase

Efter incheckning, gör inte ombasering eller ÄterstÀllning.

--commit-url <URL>

Incheckning till denna SVN-URL (den fullstÀndiga sökvÀgen). Detta Àr avsett att tillÄta att befintliga git svn-kodförrÄd som skapats med en transportmetod (t.ex. svn:// eller http:// för anonym lÀsning) ÄteranvÀnds om en anvÀndare senare ges Ätkomst till en alternativ transportmetod (t.ex. svn+ssh:// eller https://) för incheckning.

konfigurationsnyckel: svn-remote.<namn>.commiturl
konfigurationsnyckel: svn.commiturl (skriver över alla svn-remote.<namn>.commiturl-alternativ)

Observera att SVN-URL:en för konfigurationsnyckeln commiturl inkluderar SVN-grenen. Om du i stÀllet vill ange commit-URL för ett helt SVN-kodförrÄd, anvÀnd svn-remote.<namn>.pushurl.

Att anvÀnda detta alternativ för nÄgot annat ÀndamÄl (frÄga inte) avrÄds starkt.

--mergeinfo=<sammanslagningsinfo>

LÀgg till angiven sammanslagningsinformation under dcommit (t.ex. --mergeinfo="/branches/foo:1-10"). Alla svn-serverversioner kan lagra denna information (som en egenskap), och svn-klienter frÄn och med version 1.5 kan anvÀnda den. För att ange sammanslagningsinformation frÄn flera grenar, anvÀnd ett enda mellanslag mellan grenarna (--mergeinfo="/branches/foo:1-10 /branches/bar:3,5-6,8")

konfigurationsnyckel: svn.pushmergeinfo

Det hÀr alternativet gör att git-svn försöker fylla i egenskapen svn:mergeinfo i SVN-kodförrÄdet automatiskt nÀr det Àr möjligt. För nÀrvarande kan detta bara göras vid dcommit av icke-fast-forward-sammanslagningar dÀr alla förÀldrar utom den första redan har skickats till SVN.

--interactive

Be anvÀndaren att bekrÀfta att en patchuppsÀttning faktiskt ska skickas till SVN. För varje patch kan man svara "ja" (acceptera denna patch), "nej" (kassera denna patch), "alla" (acceptera alla patchar) eller "avsluta".

git svn dcommit returnerar omedelbart om svaret Àr "nej" eller "avsluta", utan att checka in nÄgot till SVN.

branch

Skapa en gren i SVN-kodförrÄdet.

-m
--message

TillÄter att ange incheckningsmeddelandet.

-t
--tag

Skapa en tagg genom att anvÀnda tags_subdir i stÀllet för branches_subdir som angavs under git svn init.

-d<sökvÀg>
--destination=<sökvÀg>

Om fler Àn ett --branches (eller --tags)-alternativ har angetts för kommandot init eller clone mÄste du ange platsen för den gren (eller tagg) du vill skapa i SVN-kodförrÄdet. <sökvÀg> anger vilken sökvÀg som ska anvÀndas för att skapa grenen eller taggen och ska matcha mönstret till vÀnster om en av de konfigurerade grenarnas eller taggarnas refspecs. Du kan se dessa refspecs med kommandona

git config --get-all svn-remote.<namn>.branches git config --get-all svn-remote.<namn>.tags

dÀr <namn> Àr namnet pÄ SVN-kodförrÄdet som anges av -R-alternativet till init (eller "svn" som standard).

--username

Ange SVN-anvÀndarnamnet som incheckningen ska utföras som. Det hÀr alternativet ÄsidosÀtter konfigurationsegenskapen username.

--commit-url

AnvÀnd den angivna URL:en för att ansluta till Subversion-mÄlkodförrÄdet. Detta Àr anvÀndbart nÀr kÀll-SVN-kodförrÄdet Àr skrivskyddat. Det hÀr alternativet ÄsidosÀtter konfigurationsegenskapen commiturl.

git config --get-all svn-remote.<namn>.commiturl
--parents

Skapa överordnade mappar. Den hÀr parametern motsvarar parametern --parents pÄ svn cp-kommandon och Àr anvÀndbar för icke-standardiserade kodförrÄds-layouter.

tag

Skapa en tagg i SVN-kodförrÄdet. Detta Àr en förkortning för branch -t.

log

Det hÀr borde göra det enkelt att slÄ upp svn-loggmeddelanden nÀr svn-anvÀndare hÀnvisar till -r/--revisionsnummer.

Följande funktioner frĂ„n ‘svn log’ stöds:

-r <n>[:<n>]
--revision=<n>[:<n>]

stöds, icke-numeriska argument stöds inte: HEAD, NEXT, BASE, PREV, etc 
​

-v
--verbose

Det Àr inte helt kompatibelt med --verbose-utdata i svn-loggen, men relativt nÀra.

--limit=<n>

Àr INTE samma sak som --max-count, rÀknar inte sammanslagna/exkluderade incheckningar

--incremental

stöds

Nya funktioner:

--show-commit

visar Àven Git-incheckningens sha1

--oneline

vÄr version av --pretty=oneline

Note
 SVN lagrar bara tider i UTC och inget annat. Den vanliga svn-klienten konverterar UTC-tiden till lokal tid (eller baserat pÄ TZ=-miljön). Det hÀr kommandot har samma beteende.

Alla andra argument skickas direkt till git log

blame

Visa vilken revision och författare som senast Àndrade varje rad i en fil. Utdata i detta lÀge Àr som standard formatkompatibel med utdata frÄn svn blame. Precis som i SVN-kommandot blame ignoreras lokala oincheckade Àndringar i arbetstrÀdet; versionen av filen i HEAD-revisionen annoteras. OkÀnda argument skickas direkt till git blame.

--git-format

Producera utdata i samma format som git blame, men med SVN-revisionsnummer i stÀllet för Git-incheckningshashar. I det hÀr lÀget visas Àndringar som inte har checkats in till SVN (inklusive lokala redigeringar i arbetskopian) som revision 0.

find-rev

NÀr ett SVN-revisionsnummer av formen rN anges returneras motsvarande Git-incheckningshash (detta kan valfritt följas av en tree-ish för att ange vilken gren som ska genomsökas). NÀr en tree-ish anges returneras motsvarande SVN-revisionsnummer.

-B
--before

KrÀv inte en exakt matchning om en SVN-revision anges, utan hitta i stÀllet den incheckning som motsvarar tillstÄndet i SVN-kodförrÄdet (pÄ aktuell gren) vid den angivna revisionen.

-A
--after

KrÀv inte en exakt matchning om en SVN-revision anges; om ingen exakt matchning finns, returnera den nÀrmaste matchningen vid sökning framÄt i historiken.

set-tree

Du bör övervÀga att anvÀnda dcommit i stÀllet för detta kommando. Checka in angivna inchecknings- eller trÀdobjekt till SVN. Detta förutsÀtter att importerade hÀmtningsdata Àr uppdaterade. Kommandot försöker inte alls patcha vid incheckning till SVN, utan skriver helt enkelt över filer med dem som anges i trÀdet eller incheckningen. All sammanslagning antas ha skett oberoende av git svn-funktionerna.

create-ignore

Hittar rekursivt egenskaperna svn:ignore och svn:global-ignores i kataloger och skapar matchande .gitignore-filer. De resulterande filerna köas för incheckning, men checkas inte in. AnvÀnd -r/--revision för att referera till en specifik revision.

show-ignore

Söker rekursivt efter och listar egenskaperna svn:ignore och svn:global-ignores i kataloger. Utdata Àr lÀmpliga för att lÀggas till i filen $GIT_DIR/info/exclude.

mkdirs

Försöker Äterskapa tomma kataloger som Git inte kan spÄra baserat pÄ information i $GIT_DIR/svn/<refnamn>/unhandled.log-filer. Tomma kataloger Äterskapas automatiskt nÀr "git svn clone" och "git svn rebase" anvÀnds, sÄ "mkdirs" Àr avsedd att anvÀndas efter kommandon som "git checkout" eller "git reset". (Se konfigurationsfilsalternativet svn-remote.<namn>.automkdirs för mer information.)

commit-diff

Checkar in diffen mellan tvÄ tree-ish-argument frÄn kommandoraden. Kommandot krÀver inte att du befinner dig i ett kodförrÄd som har git svn init-ierats. Kommandot tar tre argument: (a) originaltrÀdet att diffa mot, (b) resultatet i det nya trÀdet, (c) URL:en till Subversion-mÄlkodförrÄdet. Det sista argumentet (URL:en) kan utelÀmnas om du arbetar frÄn ett git svn-medvetet kodförrÄd (som har initierats med git svn). Alternativet -r<revision> krÀvs för detta.

Incheckningsmeddelandet anges antingen direkt med -m eller -F, eller indirekt frÄn taggen eller incheckningen nÀr den andra tree-ish betecknar ett sÄdant objekt, eller sÄ begÀrs det genom att en redigerare startas (se --edit nedan).

-m <medd>
--message=<medd>

AnvÀnd det givna medd som incheckningsmeddelande. Detta alternativ inaktiverar --edit.

-F <filnamn>
--file=<filnamn>

Ta incheckningsmeddelandet frÄn den angivna filen. Detta alternativ inaktiverar --edit.

info

Visar information om en fil eller katalog liknande den som ‘svn info’ tillhandahĂ„ller. Stöder för nĂ€rvarande inte argumentet -r/--revision. AnvĂ€nd alternativet --url för att endast mata ut vĂ€rdet frĂ„n fĂ€ltet URL:.

proplist

Listar egenskaperna som lagras i Subversion-kodförrÄdet för en given fil eller katalog. AnvÀnd -r/--revision för att referera till en specifik Subversion-revision.

propget

HÀmtar Subversion-egenskapen som första argument för en fil. En specifik revision kan anges med -r/--revision.

propset

StÀller in Subversion-egenskapen som anges som det första argumentet, till vÀrdet som anges som det andra argumentet för filen som anges som det tredje argumentet.

Exempel:

git svn propset svn:keywords "FreeBSD=%H" devel/py-tipper/Makefile

Det hÀr kommer att stÀlla in egenskapen svn:keywords till FreeBSD=%H för filen devel/py-tipper/Makefile.

show-externals

Visar Subversions externa element. AnvÀnd -r/--revision för att ange en specifik revision.

gc

Komprimera $GIT_DIR/svn/<refnamn>/unhandled.log filerna och ta bort $GIT_DIR/svn/<refnamn>/index-filerna.

reset

Ångrar effekterna av fetch (hĂ€mta) tillbaka till den angivna revisionen. Detta lĂ„ter dig Ă„ter-fetch en SVN-revision. Normalt sett bör innehĂ„llet i en SVN-revision aldrig Ă€ndras och Ă„terstĂ€ll bör inte vara nödvĂ€ndigt. Men om SVN-behörigheter Ă€ndras, eller om du Ă€ndrar alternativet --ignore-paths, kan en hĂ€mtning misslyckas med "hittades inte i incheckning" (filen var inte synlig tidigare) eller "checksumma missmatchning" (en Ă€ndring missades). Om problemfilen inte kan ignoreras för alltid (med --ignore-paths) Ă€r det enda sĂ€ttet att reparera kodförrĂ„det att anvĂ€nda Ă„terstĂ€ll.

Endast rev_map och refs/remotes/git-svn Àndras (se $GIT_DIR/svn/**/.rev_map.* i avsnittet FILER nedan för detaljer). Följ reset med en fetch och sedan git reset eller git rebase för att flytta lokala grenar till det nya trÀdet.

-r <n>
--revision=<n>

Ange den senaste versionen som ska behÄllas. Alla senare versioner ignoreras.

-p
--parent

SlÀng Àven den angivna revisionen och behÄll i stÀllet den nÀrmaste förÀldern.

Exempel:

Anta att du har lokala Àndringar i "master", men att du behöver hÀmta "r2" pÄ nytt.

    r1---r2---r3 remotes/git-svn
                \
                 A---B master

ÅtgĂ€rda problemet med ignore-paths eller SVN-behörigheter som orsakade att "r2" var ofullstĂ€ndig frĂ„n första början. Sedan:

git svn reset -r2 -p
git svn fetch
    r1---r2'--r3' remotes/git-svn
      \
       r2---r3---A---B master

Fixa sedan "master" med git rebase. AnvÀnd INTE git merge, annars kommer din historik inte att vara kompatibel med en framtida dcommit!

git rebase --onto remotes/git-svn A^ master
    r1---r2'--r3' remotes/git-svn
                \
                 A'--B' master

ALTERNATIV

--shared[=(false|true|umask|group|all|world|everybody)]
--template=<mall-katalog>

AnvÀnds endast med kommandot init. Dessa skickas direkt till git init.

-r <arg>
--revision <arg>

AnvÀnds med fetch kommandot.

Det hÀr möjliggör stöd för revisionsintervall för partiell/avkortad historik. $NUMBER, $NUMBER1:$NUMBER2 (numeriska intervall), $NUMBER:HEAD och BASE:$NUMBER stöds alla.

Det hÀr kan tillÄta dig att skapa partiella speglingar nÀr du kör hÀmtning; men rekommenderas generellt inte eftersom historiken kommer att hoppas över och förloras.

-
--stdin

AnvÀnds endast med kommandot set-tree.

LÀs en lista med incheckningar frÄn stdin och checka in dem i omvÀnd ordning. Endast den inledande sha1 lÀses frÄn varje rad, sÄ utdata frÄn git rev-list --pretty=oneline kan anvÀndas.

--rmdir

AnvÀnds endast med kommandona dcommit, set-tree och commit-diff.

Ta bort kataloger frÄn SVN-trÀdet om det inte finns nÄgra filer kvar. SVN kan versionslÀsa tomma kataloger, och de tas inte bort som standard om det inte finns nÄgra filer kvar i dem. Git kan inte versionslÀsa tomma kataloger. Om du aktiverar den hÀr flaggan kommer incheckning till SVN att agera som Git.

konfigurationsnyckel: svn.rmdir
-e
--edit

AnvÀnds endast med kommandona dcommit, set-tree och commit-diff.

Redigera incheckningsmeddelandet innan det checkas in till SVN. Detta Àr avstÀngt som standard för objekt som Àr incheckningar och tvingas aktiverat vid incheckning av trÀdobjekt.

konfigurationsnyckel: svn.edit
-l<num>
--find-copies-harder

AnvÀnds endast med kommandona dcommit, set-tree och commit-diff.

BÄda skickas direkt till git diff-tree; se git-diff-tree[1] för mer information.

konfigurationsnyckel: svn.l
konfigurationsnyckel: svn.findcopiesharder
-A<filnamn>
--authors-file=<filnamn>

Syntaxen Àr kompatibel med filen som anvÀnds av git cvsimport men en tom e-postadress kan anges med <>:

	loginname = Joe User <user@example.com>

Om det hÀr alternativet anges och git svn stöter pÄ ett SVN-incheckare-namn som inte finns i authors-filen, kommer git svn att avbryta ÄtgÀrden. AnvÀndaren mÄste dÄ lÀgga till lÀmplig post. Att köra det föregÄende git svn-kommandot igen efter att authors-filen har Àndrats bör fortsÀtta ÄtgÀrden.

konfigurationsnyckel: svn.authorsfile
--authors-prog=<filnamn>

Om det hÀr alternativet anges, körs filen med incheckare-namnet som första argument för varje SVN-incheckare-namn som inte finns i authors-filen. Programmet förvÀntas returnera en enda rad av formen "Namn <e-postadress>" eller "Namn <>", vilken kommer att behandlas som om den inkluderades i authors-filen.

Av historiska skÀl söks först ett relativt filnamn relativt till den aktuella katalogen för init och clone och relativt till roten av arbetstrÀdet för fetch. Om filnamn inte hittas söks det som vilket annat kommando som helst i $PATH.

konfigurationsnyckel: svn.authorsProg
-q
--quiet

Gör git svn mindre utförlig. Specificera en andra gÄng för att göra det Ànnu mindre utförligt.

-m
--merge
-s<strategi>
--strategy=<strategi>
-p
--rebase-merges

Dessa anvÀnds endast med kommandona dcommit och rebase.

Skickas direkt till git rebase nÀr dcommit anvÀnds om en git reset inte kan anvÀndas (se dcommit).

-n
--dry-run

Det hÀr kan anvÀndas med kommandona dcommit, rebase, branch och tag.

För dcommit, skriv ut serien med Git-argument som skulle visa vilka diffar som skulle ha checkats in till SVN.

För rebase, visa den lokala grenen som Àr associerad med det uppströms svn-kodförrÄdet som Àr associerat med den aktuella grenen och URL:en för det svn-kodförrÄd som ska hÀmtas frÄn.

För branch och tag, visa de webbadresser som ska anvÀndas för kopiering nÀr grenen eller taggen skapas.

--use-log-author

NÀr du hÀmtar svn-incheckningar till Git (som en del av operationerna fetch, rebase eller dcommit), leta efter den första From:-raden eller Signed-off-by-slutraden i loggmeddelandet och anvÀnd den som författarstrÀng.

konfigurationsnyckel: svn.useLogAuthor
--add-author-from

NÀr du checkar in till svn frÄn Git (som en del av set-tree- eller dcommit-operationer), och om det befintliga loggmeddelandet inte redan har en From:- eller Signed-off-by-slutrad, lÀgg till en From:-rad baserat pÄ Git-incheckningens författarstrÀng. Om du anvÀnder detta kommer --use-log-author att hÀmta en giltig författarstrÀng för alla incheckningar.

konfigurationsnyckel: svn.addAuthorFrom

AVANCERADE ALTERNATIV

-i<GIT_SVN_ID>
--id <GIT_SVN_ID>

Det hÀr stÀller in GIT_SVN_ID (i stÀllet för att anvÀnda miljön). Detta gör det möjligt för anvÀndaren att ÄsidosÀtta standardreferensnamnet som hÀmtas frÄn nÀr en enskild URL spÄras. Kommandona log och dcommit krÀver inte lÀngre denna vÀxel som argument.

-R<fjÀrr-namn>
--svn-remote <fjÀrr-namn>

Ange avsnittet [svn-remote "<fjÀrr-namn>"] som ska anvÀndas; detta gör att flera SVN-kodförrÄd kan spÄras. Standard: "svn"

--follow-parent

Det hÀr alternativet Àr endast relevant om vi spÄrar grenar (med hjÀlp av ett av layoutflaggor för kodförrÄd --trunk, --tags, --branches, --stdlayout). För varje spÄrad gren, försök att ta reda pÄ var dess version kopierades ifrÄn och ange en lÀmplig förÀlder i den första Git-incheckningen för grenen. Detta Àr sÀrskilt anvÀndbart nÀr vi spÄrar en katalog som har flyttats runt inom kodförrÄdet. Om den hÀr funktionen Àr inaktiverad kommer grenarna som skapats av git svn alla att vara linjÀra och inte dela nÄgon historik, vilket innebÀr att det inte kommer att finnas nÄgon information om var grenar förgrenades eller slogs samman. Att följa lÄnga/komplicerade historiker kan dock ta lÄng tid, sÄ att inaktivera den hÀr funktionen kan pÄskynda kloningsprocessen. Den hÀr funktionen Àr aktiverad som standard, anvÀnd --no-follow-parent för att inaktivera den.

konfigurationsnyckel: svn.followparent

ALTERNATIV ENDAST FÖR KONFIGURATIONSFIL

svn.noMetadata
svn-remote.<namn>.noMetadata

Det hÀr tar bort raderna git-svn-id: i slutet av varje incheckning.

Det hÀr alternativet kan bara anvÀndas för engÄngsimporter eftersom git svn inte kommer att kunna hÀmtas igen utan metadata. Om du dessutom förlorar dina $GIT_DIR/svn/**/.rev_map.*-filer kommer git svn inte att kunna Äterskapa dem.

Kommandot git svn log fungerar inte heller pÄ kodförrÄd som anvÀnder detta. Att anvÀnda detta stÄr i konflikt med alternativet useSvmProps av (förhoppningsvis) uppenbara skÀl.

Det hÀr alternativet rekommenderas INTE eftersom det försvÄrar spÄrning av Àldre referenser till SVN-revisionsnummer i befintlig dokumentation, felrapporter och arkiv. Om du planerar att sÄ smÄningom migrera frÄn SVN till Git och Àr sÀker pÄ att du kan slÀppa SVN-historiken, övervÀg i stÀllet git-filter-repo. filter-repo kan ocksÄ formatera om metadata för bÀttre lÀsbarhet och skriva om författarinformation för anvÀndare som inte anvÀnder "svn.authorsFile".

svn.useSvmProps
svn-remote.<namn>.useSvmProps

Det hÀr gör det möjligt för git svn att ommappa kodförrÄdets URL:er och UUID:er frÄn speglar skapade med SVN::Mirror (eller svk) för metadata.

Om en SVN-revision har egenskapen "svm:headrev" Àr det troligt att revisionen skapades av SVN::Mirror (som Àven anvÀnds av SVK). Egenskapen innehÄller ett UUID för kodförrÄdet och en revision. Vi vill att det ska se ut som att vi speglar den ursprungliga URL:en, sÄ vi introducerar en hjÀlpfunktion som returnerar den ursprungliga identitets-URL:en och UUID:t, och anvÀnder den nÀr vi genererar metadata i incheckningsmeddelanden.

svn.useSvnsyncProps
svn-remote.<namn>.useSvnsyncprops

Liknar alternativet useSvmProps; detta Àr för anvÀndare av kommandot svnsync(1) som distribueras med SVN 1.4.x och senare.

svn-remote.<namn>.rewriteRoot

Det hÀr gör det möjligt för anvÀndare att skapa kodförrÄd frÄn alternativa URL:er. Till exempel kan en administratör köra git svn lokalt pÄ servern (Ätkomst via file://) men vilja distribuera kodförrÄdet med en offentlig http://- eller svn://-URL i metadata sÄ att anvÀndarna ser den offentliga URL:en.

svn-remote.<namn>.rewriteUUID

Liknar alternativet useSvmProps; detta Àr för anvÀndare som behöver mappa om UUID manuellt. Detta kan vara anvÀndbart i situationer dÀr det ursprungliga UUID inte Àr tillgÀngligt via vare sig useSvmProps eller useSvnsyncProps.

svn-remote.<namn>.pushurl

I likhet med Gits remote.<namn>.pushurl Àr denna nyckel utformad för att anvÀndas i fall dÀr url pekar till ett SVN-kodförrÄd via en skrivskyddad transport, för att tillhandahÄlla en alternativ lÀs-/skrivtransport. Det antas att bÄda nycklarna pekar till samma kodförrÄd. Till skillnad frÄn commiturl Àr pushurl en bassökvÀg. Om antingen commiturl eller pushurl kan anvÀndas, har commiturl företrÀde.

svn.brokenSymlinkWorkaround

Det hÀr inaktiverar potentiellt dyra kontroller för att kringgÄ trasiga symboliska lÀnkar som checkats in i SVN av trasiga klienter. StÀll in det hÀr alternativet till "false" om du spÄrar ett SVN-kodförrÄd med mÄnga tomma blobbar som inte Àr symboliska lÀnkar. Det hÀr alternativet kan Àndras medan git svn körs och trÀda i kraft vid nÀsta hÀmtade version. Om det inte Àr instÀllt antar git svn att det hÀr alternativet Àr "sant".

svn.pathnameencoding

Det hÀr instruerar git svn att omkoda sökvÀgar till en given kodning. Det kan anvÀndas av Windows-anvÀndare och av de som arbetar i icke-UTF8-sprÄk för att undvika korrupta filnamn med icke-ASCII-tecken. Giltiga kodningar Àr de som stöds av Perls Encode-modul.

svn-remote.<namn>.automkdirs

Normalt sett försöker kommandona "git svn clone" och "git svn rebase" att Äterskapa tomma kataloger som finns i Subversion-kodförrÄdet. Om det hÀr alternativet Àr satt till "false" kommer tomma kataloger endast att skapas om kommandot "git svn mkdirs" körs explicit. Om det inte Àr satt antar git svn att det hÀr alternativet Àr "sant".

Eftersom alternativen noMetadata, rewriteRoot, rewriteUUID, useSvnsyncProps och useSvmProps alla pÄverkar metadata som genereras och anvÀnds av git svn, mÄste de stÀllas in i konfigurationsfilen innan nÄgon historik importeras och dessa instÀllningar bör aldrig Àndras nÀr de vÀl Àr instÀllda.

Dessutom kan endast ett av dessa alternativ anvÀndas per svn-remote-sektion eftersom de pÄverkar metadataraden git-svn-id:, förutom rewriteRoot och rewriteUUID som kan anvÀndas tillsammans.

GRUNDLÄGGANDE EXEMPEL

SpÄra och bidra till trunk för ett Subversion-hanterat projekt (ignorerar taggar och grenar):

# Klona ett kodförrÄd med standard SVN-kataloglayout (som git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Eller, om kodförrÄdet anvÀnder en icke-standardiserad kataloglayout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# Visa alla grenar och taggar du har klonat:
	git branch -r
# Skapa en ny gren i SVN
	git svn branch waldo
# ÅterstĂ€ll din master till trunk (eller nĂ„gon annan gren, ersĂ€tt 'trunk'
# med lÀmpligt namn):
	git reset --hard svn/trunk
# Du kan bara dcommit till en gren/tagg/trunk Ät gÄngen. AnvÀndningen
# av dcommit/rebase/show-ignore bör vara densamma som ovan.

SpÄra och bidra till ett helt Subversion-hanterat projekt (komplett med en trunk, taggar och grenar):

# Klona ett kodförrÄd med standard SVN-kataloglayout (som git clone):
	git svn clone http://svn.example.com/project --stdlayout --prefix svn/
# Eller, om kodförrÄdet anvÀnder en icke-standardiserad kataloglayout:
	git svn clone http://svn.example.com/project -T tr -b branch -t tag --prefix svn/
# Visa alla grenar och taggar du har klonat:
	git branch -r
# Skapa en ny gren i SVN
	git svn branch waldo
# ÅterstĂ€ll din master till trunk (eller nĂ„gon annan gren, ersĂ€tt 'trunk'
# med lÀmpligt namn):
	git reset --hard svn/trunk
# Du kan bara dcommit till en gren/tagg/trunk Ät gÄngen. AnvÀndningen
# av dcommit/rebase/show-ignore bör vara densamma som ovan.

Den första git svn clone kan vara ganska tidskrÀvande (sÀrskilt för stora Subversion-kodförrÄd). Om flera personer (eller en person med flera maskiner) vill anvÀnda git svn mot samma Subversion-kodförrÄd, kan du göra den initiala git svn clone till ett kodförrÄd pÄ en server och lÄta varje person klona det kodförrÄdet med git clone:

# Gör den initiala importen pÄ en server
	ssh server "cd /pub && git svn clone http://svn.example.com/project [options...]"
# Klona lokalt - se till att refs/remotes/-utrymmet matchar serverns
	mkdir project
	cd project
	git init
	git remote add origin server:/pub/project
	git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
	git fetch
# Förhindra fetch/pull frÄn fjÀrr-Git-servern i framtiden,
# vi vill bara anvÀnda git svn för framtida uppdateringar
	git config --remove-section remote.origin
# Skapa en lokal gren frÄn en av de grenar som just hÀmtats
	git checkout -b master FETCH_HEAD
# Initiera 'git svn' lokalt (se till att anvÀnda samma URL och
# --stdlayout/-T/-b/-t/--prefix alternativ som anvÀndes pÄ servern)
	git svn init http://svn.example.com/project [options...]
# HÀmta de senaste Àndringarna frÄn Subversion
	git svn rebase

REBASE MOT PULL/MERGE

Föredra att anvÀnda git svn rebase eller git rebase, snarare Àn git pull eller git merge för att synkronisera ointegrerade incheckningar med en git svn-gren. Genom att göra det hÄlls historiken för ointegrerade incheckningar linjÀr i förhÄllande till SVN-kodförrÄdet uppströms och tillÄts anvÀndning av det föredragna underkommandot git svn dcommit för att skicka tillbaka ointegrerade incheckningar till SVN.

Ursprungligen rekommenderade git svn att utvecklare skulle hÀmta eller slÄ samman frÄn grenen git svn. Det berodde pÄ att författaren föredrog git svn set-tree B för att checka in ett enda huvud, i stÀllet för notationen git svn set-tree A..B för att checka in flera incheckningar. AnvÀndning av git pull eller git merge med git svn set-tree A..B gör att icke-linjÀr historik plattas ut vid incheckning i SVN, och detta kan leda till att sammanslagningsincheckningar ovÀntat ÄterstÀller tidigare incheckningar i SVN.

SAMMANSLAGNINGSSPÅRNING

Även om git svn kan spĂ„ra kopieringshistorik (inklusive grenar och taggar) för kodförrĂ„d som anvĂ€nder en standardlayout, kan den Ă€nnu inte representera sammanslagningshistorik som skett inuti git tillbaka uppströms till SVN-anvĂ€ndare. DĂ€rför rekommenderas det att anvĂ€ndare hĂ„ller historiken sĂ„ linjĂ€r som möjligt inuti Git för att underlĂ€tta kompatibiliteten med SVN (se avsnittet FÖRBEHÅLL nedan).

HANTERING AV SVN-GRENAR

Om git svn Àr konfigurerad för att hÀmta grenar (och --follow-branches Àr aktivt), skapar den ibland flera Git-grenar för en SVN-gren, dÀr de ytterligare grenarna har namn av formen branchname@nnn (med nnn ett SVN-revisionsnummer). Dessa ytterligare grenar skapas om git svn inte kan hitta en överordnad incheckning för den första incheckningen i en SVN-gren, för att koppla grenen till historiken för de andra grenarna.

Normalt sett, bestÄr den första incheckningen i en SVN-gren av en kopieringsoperation. git svn lÀser denna incheckning för att hÀmta SVN-revisionen som grenen skapades frÄn. Den försöker sedan hitta Git-incheckningen som motsvarar denna SVN-revision och anvÀnder den som förÀlder till grenen. Det Àr dock möjligt att det inte finns nÄgon lÀmplig Git-incheckning som kan fungera som förÀlder. Detta hÀnder bland annat om SVN-grenen Àr en kopia av en revision som inte hÀmtades av git svn (t.ex. för att det Àr en gammal revision som hoppades över med --revision), eller om en katalog kopierades i SVN som inte spÄras av git svn (t.ex. en gren som inte spÄras alls, eller en underkatalog till en spÄrad gren). I dessa fall kommer git svn fortfarande att skapa en Git-gren, men i stÀllet för att anvÀnda en befintlig Git-incheckning som förÀlder till grenen, kommer den att lÀsa SVN-historiken för katalogen som grenen kopierades frÄn och skapa lÀmpliga Git-incheckningar. Detta indikeras av meddelandet "Initierar förÀlder: <grennamn>".

Dessutom skapas en speciell gren med namnet <branchname>@<SVN-Revision>, dÀr <SVN-Revision> Àr SVN-revisionsnumret som grenen kopierades frÄn. Denna gren pekar pÄ den nyskapade förÀldra-incheckningen för grenen. Om grenen i SVN raderades och senare Äterskapades frÄn en annan version, kommer det att finnas flera sÄdana grenar med ett @.

Observera att detta kan innebÀra att flera Git-incheckningar skapas för en enda SVN-revision.

Ett exempel: i ett SVN-kodförrÄd med en standardlayout för trunk/tags/branches skapas en katalog trunk/sub i r.100. I r.200 förgrenas trunk/sub genom att kopieras till branches/. git svn clone -s skapar sedan en gren sub. Den skapar ocksÄ nya Git-incheckningar för r.100 till r.199 och anvÀnder dessa som historik för grenen sub. SÄledes kommer det att finnas tvÄ Git-incheckningar för varje revision frÄn r.100 till r.199 (en som innehÄller trunk/, en som innehÄller trunk/sub/). Slutligen skapar den en gren sub@200 som pekar pÄ den nya överordnade incheckningen för grenen sub (d.v.s. incheckningen för r.200 och trunk/sub/).

FÖRBEHÅLL

För enkelhetens skull och för att interagera med Subversion rekommenderas det att alla git svn-anvÀndare klonar, hÀmtar och dcommitar direkt frÄn SVN-servern, och undviker alla git clone/pull/merge/push-operationer mellan Git-kodförrÄd och grenar. Den rekommenderade metoden för att utbyta kod mellan Git-grenar och anvÀndare Àr git format-patch och git am, eller bara dcommit till SVN-kodförrÄdet.

Att köra git merge eller git pull rekommenderas INTE pÄ en gren du planerar att dcommit frÄn eftersom Subversion-anvÀndare inte kan se nÄgra sammanslagningar du har gjort. Dessutom, om du sammanslÄr (merge) eller drar (pull) frÄn en Git-gren som Àr en spegel av en SVN-gren, kan dcommit checka in till fel gren.

Om du sammanslÄr (merge), observera följande regel: git svn dcommit kommer att försöka checka in ovanpÄ SVN-incheckningen som namnges i

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

Du mÄste dÀrför se till att den senaste incheckningsfilen för den gren du vill dcommit:a till Àr den första förÀldern till sammanslagningen. Annars kommer det att bli kaos, sÀrskilt om den första förÀldern Àr en Àldre incheckning pÄ samma SVN-gren.

git clone klonar inte grenar under hierarkin refs/remotes/ eller nÄgon git svn-metadata eller konfiguration. SÄ kodförrÄd som skapats och hanteras med git svn bör anvÀnda rsync för kloning, om kloning ska göras överhuvudtaget.

Eftersom dcommit anvÀnder ombasering internt kommer alla Git-grenar som du kör git push till före dcommit att krÀva att den befintliga referensen i fjÀrrkodförrÄdet skrivs över med tvÄng. Detta anses i allmÀnhet vara dÄlig praxis; se dokumentationen för git-push[1] för detaljer.

AnvÀnd inte alternativet --amend i git-commit[1] pÄ en Àndring som du redan har dcommitat. Det anses vara dÄlig praxis att anvÀnda --amend pÄ incheckningar som du redan har skickat till ett fjÀrrkodförrÄd för andra anvÀndare, och dcommit med SVN Àr analogt med det.

NĂ€r du klonar ett SVN-kodförrĂ„d och inga alternativ för att beskriva kodförrĂ„dets layout anvĂ€nds (--trunk, --tags, --branches, --stdlayout), skapar git svn clone ett Git-kodförrĂ„d med helt linjĂ€r historik, dĂ€r grenar och taggar visas som separata kataloger i arbetskopian. Även om detta Ă€r det enklaste sĂ€ttet att fĂ„ en kopia av ett komplett kodförrĂ„d, leder det för projekt med mĂ„nga grenar till en arbetskopia som Ă€r mĂ„nga gĂ„nger större Ă€n bara trunk. DĂ€rför rekommenderas projekt som anvĂ€nder standardstrukturen (trunk/branches/tags) att klona med --stdlayout. Om projektet anvĂ€nder en icke-standardstruktur, och/eller om grenar och taggar inte behövs, Ă€r det enklast att bara klona en katalog (vanligen trunk) utan layoutalternativ. Om full historik med grenar och taggar krĂ€vs mĂ„ste alternativen --trunk / --branches / --tags anvĂ€ndas.

NÀr man anvÀnder flera --branches eller --tags hanterar git svn inte automatiskt namnkollisioner (till exempel om tvÄ grenar frÄn olika sökvÀgar har samma namn, eller om en gren och en tagg har samma namn). I dessa fall, anvÀnd init för att konfigurera ditt Git-kodförrÄd och redigera sedan, innan din första fetch, $GIT_DIR/config-filen sÄ att grenarna och taggarna Àr associerade med olika namnrymder. Till exempel:

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

KONFIGURATION

git svn lagrar [svn-remote]-konfiguration i kodförrÄdets fil $GIT_DIR/config. Detta liknar Gits vanliga [remote]-sektioner, förutom att fetch-nycklar inte accepterar glob-argument; de hanteras i stÀllet av nycklarna branches och tags. Eftersom vissa SVN-kodförrÄd Àr ovanligt konfigurerade med flera projekt Àr glob-expansioner som de nedan tillÄtna:

[svn-remote "project-a"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	branches = branches/*/project-a:refs/remotes/project-a/branches/*
	branches = branches/release_*:refs/remotes/project-a/branches/release_*
	branches = branches/re*se:refs/remotes/project-a/branches/*
	tags = tags/*/project-a:refs/remotes/project-a/tags/*

TÀnk pÄ att * (asterisk) för den lokala referensen (till höger om :) mÄste vara den lÀngst till höger belÀgna sökvÀgskomponenten; fjÀrr jokertecknet kan dock finnas var som helst sÄ lÀnge det Àr en oberoende sökvÀgskomponent (omgiven av / eller EOL). Denna typ av konfiguration skapas inte automatiskt av init och bör anges manuellt med en textredigerare eller med hjÀlp av git config.

Observera ocksÄ att endast en asterisk Àr tillÄten per ord. Till exempel:

branches = branches/re*se:refs/remotes/project-a/branches/*

kommer dock att matcha grenarna release, rese, re123se

branches = branches/re*s*e:refs/remotes/project-a/branches/*

kommer att producera ett fel.

Det Àr ocksÄ möjligt att hÀmta en delmÀngd av grenar eller taggar genom att anvÀnda en kommaseparerad lista med namn inom klammerparenteser. Till exempel:

[svn-remote "huge-project"]
	url = http://server.org/svn
	fetch = trunk/src:refs/remotes/trunk
	branches = branches/{red,green}/src:refs/remotes/project-a/branches/*
	tags = tags/{1.0,2.0}/src:refs/remotes/project-a/tags/*

Flera hÀmtnings-, gren- och tagg-nycklar stöds:

[svn-remote "messy-repo"]
	url = http://server.org/svn
	fetch = trunk/project-a:refs/remotes/project-a/trunk
	fetch = branches/demos/june-project-a-demo:refs/remotes/project-a/demos/june-demo
	branches = branches/server/*:refs/remotes/project-a/branches/*
	branches = branches/demos/2011/*:refs/remotes/project-a/2011-demos/*
	tags = tags/server/*:refs/remotes/project-a/tags/*

Att skapa en gren i en sÄdan konfiguration krÀver att man tydliggör vilken plats som ska anvÀndas med hjÀlp av flaggan -d eller --destination:

$ git svn branch -d branches/server release-2-3-0

Observera att git-svn hÄller reda pÄ den högsta versionen dÀr en gren eller tagg har förekommit. Om delmÀngden av grenar eller taggar Àndras efter hÀmtning, mÄste $GIT_DIR/svn/.metadata redigeras manuellt för att ta bort (eller ÄterstÀlla) branches-maxRev och/eller tags-maxRev efter behov.

FILER

$GIT_DIR/svn/**/.rev_map.*

Mappning mellan Subversion-revisionsnummer och Git-cincheckningsnamn. I ett repository dÀr alternativet noMetadata inte Àr angivet kan detta byggas om frÄn git-svn-id:-raderna som finns i slutet av varje incheckning (se avsnittet svn.noMetadata ovan för mer information).

git svn fetch och git svn rebase uppdaterar automatiskt rev_map om den saknas eller inte Àr uppdaterad. git svn reset spolar tillbaka den automatiskt.

BUGGAR

Vi ignorerar alla SVN-egenskaper förutom svn:executable. Alla ohanterade egenskaper loggas till $GIT_DIR/svn/<refnamn>/unhandled.log

Omdöpta och kopierade kataloger upptÀcks inte av Git och spÄras dÀrför inte vid incheckning till SVN. Jag planerar inte att lÀgga till stöd för detta eftersom det Àr ganska svÄrt och tidskrÀvande att fÄ att fungera för alla möjliga grÀnsfall (Git gör det inte heller). Att checka in omdöpta och kopierade filer stöds fullt ut om de Àr tillrÀckligt lika för att Git ska kunna upptÀcka dem.

I SVN Àr det möjligt (men avrÄds) att göra Àndringar i en tagg (eftersom en tagg bara Àr en katalogkopia, alltsÄ tekniskt sett samma sak som en gren). NÀr man klonar ett SVN-kodförrÄd kan git svn inte veta om en sÄdan incheckning till en tagg kommer att ske i framtiden. DÀrför agerar den konservativt och importerar alla SVN-taggar som grenar, med prefixet tags/ före taggnamnet.

SE ÄVEN

git-rebase[1]

GIT

En del av git[1]-sviten