Zoeken…
Opmerkingen
Klonen van zeer grote SVN-opslagplaatsen
Als je SVN-repogeschiedenis echt heel groot is, kan deze bewerking uren duren, omdat git-svn de volledige geschiedenis van de SVN-repo opnieuw moet opbouwen. Gelukkig hoef je de SVN-repo slechts eenmaal te klonen; net als bij elke andere git-repository kun je de repomap gewoon naar andere bijdragers kopiëren. Het kopiëren van de map naar meerdere computers gaat sneller dan alleen het kopiëren van grote SVN-repo's vanaf nul.
Over commits en SHA1
Je lokale git commits worden herschreven als je het commando git svn dcommit . Dit commando zal een tekst toevoegen aan het bericht van de git commit met verwijzing naar de SVN-revisie gemaakt op de SVN-server, wat erg handig is. Het toevoegen van een nieuwe tekst vereist echter het wijzigen van het bericht van een bestaande commit, wat eigenlijk niet gedaan kan worden: git commits zijn niet-muteerbaar. De oplossing is een nieuwe commit maken met dezelfde inhoud en het nieuwe bericht, maar technisch gezien is het toch een nieuwe commit (dwz dat de SHA1 van de git commit zal veranderen)
Omdat git commits gemaakt voor git-svn lokaal zijn, verschillen de SHA1-id's voor git commits tussen elke git repository! Dit betekent dat je een SHA1 niet kunt gebruiken om te verwijzen naar een commit van een andere persoon omdat dezelfde commit een andere SHA1 zal hebben in elke lokale git repository. U moet vertrouwen op het svn-revisienummer dat aan het commit-bericht is toegevoegd wanneer u naar de SVN-server pusht als u naar een commit tussen verschillende exemplaren van de repository wilt verwijzen.
Je kunt de SHA1 wel gebruiken voor lokale bewerkingen (een specifieke commit weergeven / differen, cherry-picks en resets, enz.)
Probleemoplossen
git svn rebase commando geeft een checksum mismatch fout
Het commando git svn rebase geeft een soortgelijke fout weer:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
De oplossing voor dit probleem is om svn opnieuw in te stellen op de revisie toen het probleembestand voor de laatste keer werd gewijzigd, en voer een git svn op zodat de SVN-geschiedenis wordt hersteld. De opdrachten om de SVN-reset uit te voeren zijn:
- git log -1 -
<path_to_file>(kopieer het SVN revisienummer dat in het commit bericht verschijnt) - git svn reset
<revision_number> - git svn haal
U zou gegevens van SVN opnieuw moeten kunnen pushen / trekken
Bestand is niet gevonden in commit Wanneer je probeert op te halen of te halen van SVN krijg je een fout die lijkt op deze
<file_path> was not found in commit <hash>
Dit betekent dat een herziening in SVN een bestand probeert te wijzigen dat om de een of andere reden niet in uw lokale exemplaar voorkomt. De beste manier om van deze fout af te komen, is door een ophaalactie het pad van dat bestand te negeren en het zal worden bijgewerkt naar zijn status in de nieuwste SVN-revisie:
-
git svn fetch --ignore-paths <file_path>
Klonen van de SVN-repository
U moet een nieuwe lokale kopie van de repository maken met de opdracht
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Als uw SVN-repository de standaardlay-out volgt (trunk, branches, tags-mappen), kunt u wat typen opslaan:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone checkt elke SVN-revisie een voor een en maakt een git commit in je lokale repository om de geschiedenis opnieuw te creëren. Als de SVN-repository veel commits heeft, duurt dit even.
Wanneer de opdracht is voltooid, heb je een volwaardige git-repository met een lokale branch genaamd master die de trunk-branch in de SVN-repository volgt.
De nieuwste wijzigingen ophalen van SVN
Het equivalent van git pull is het commando
git svn rebase
Hiermee worden alle wijzigingen uit de SVN-repository opgehaald en toegepast bovenop uw lokale commits in uw huidige filiaal.
U kunt ook de opdracht gebruiken
git svn fetch
om de wijzigingen uit de SVN-repository op te halen en naar uw lokale machine te brengen, maar zonder ze op uw lokale filiaal toe te passen.
Lokale wijzigingen doorvoeren naar SVN
Het bevel
git svn dcommit
zal een SVN-revisie maken voor elk van je lokale git commits. Net als bij SVN, moet je lokale git-geschiedenis gesynchroniseerd zijn met de laatste wijzigingen in de SVN-repository, dus als de opdracht mislukt, probeer dan eerst een git svn rebase .
Lokaal werken
Gebruik gewoon je lokale git repository als een normale git repo, met de normale git commando's:
-
git add FILEengit checkout -- FILEOm een bestand te stage / unstageren -
git commitOm je wijzigingen op te slaan. Die commits zijn lokaal en worden niet "gepusht" naar de SVN-repo, net als in een normale git-repository -
git stashengit stash popHiermee kun je stashes gebruiken -
git reset HEAD --hardZet al je lokale wijzigingen terug -
git logToegang tot alle geschiedenis in de repository -
git rebase -izodat je je lokale geschiedenis vrij kunt herschrijven -
git branchengit checkoutom lokale branches te maken
Zoals de git-svn-documentatie stelt: "Subversion is een systeem dat veel minder geavanceerd is dan Git", dus je kunt niet alle kracht van git gebruiken zonder de geschiedenis in de Subversion-server te verknoeien. Gelukkig zijn de regels heel eenvoudig: houd de geschiedenis lineair
Dit betekent dat je bijna elke git-bewerking kunt uitvoeren: takken maken, commits verwijderen / opnieuw ordenen / pletten, de geschiedenis verplaatsen, commits verwijderen, etc. Alles behalve samenvoegingen . Als je de geschiedenis van lokale vestigingen opnieuw wilt integreren, gebruik dan in plaats daarvan git rebase .
Wanneer je een merge uitvoert, wordt een merge-commit gemaakt. Het bijzondere van merge commits is dat ze twee ouders hebben, en dat maakt de geschiedenis niet-lineair. Niet-lineaire geschiedenis zal SVN verwarren in het geval u een merge-commit naar de repository "pusht".
Maak je echter geen zorgen: je zult niets breken als je een git merge commit naar SVN "pusht" . Als je dit doet, wanneer de git merge commit naar de svn-server wordt verzonden, bevat deze alle wijzigingen van alle commits voor die merge, dus je verliest de geschiedenis van die commits, maar niet de wijzigingen in je code.
Omgaan met lege mappen
git herkent het concept van mappen niet, het werkt alleen met bestanden en hun bestandspaden. Dit betekent dat git geen lege mappen bijhoudt. SVN doet dat echter wel. Het gebruik van git-svn betekent dat standaard elke wijziging met lege mappen met git niet wordt doorgegeven aan SVN .
Het gebruik van de vlag --rmdir bij het geven van een reactie corrigeert dit probleem en verwijdert een lege map in SVN als u lokaal het laatste bestand erin verwijdert:
git svn dcommit --rmdir
Helaas worden bestaande lege mappen niet verwijderd : u moet dit handmatig doen.
Om te voorkomen dat je de vlag toevoegt elke keer dat je een dcommit doet, of om het veilig te spelen als je een git GUI tool (zoals SourceTree) gebruikt, kun je dit gedrag als standaard instellen met de opdracht:
git config --global svn.rmdir true
Dit wijzigt uw .gitconfig-bestand en voegt deze regels toe:
[svn]
rmdir = true
Gebruik de opdracht git om alle niet-bijgehouden bestanden en mappen te verwijderen die leeg moeten blijven voor SVN:
git clean -fd
Let op: met het vorige commando worden alle niet-bijgehouden bestanden en lege mappen verwijderd, zelfs degenen die door SVN moeten worden gevolgd! Als u againg wilt genereren met de lege mappen die worden bijgehouden door SVN, gebruikt u de opdracht
git svn mkdirs
In de praktijk betekent dit dat als u uw werkruimte wilt opruimen van niet-bijgehouden bestanden en mappen, u beide opdrachten altijd moet gebruiken om de lege mappen bijgehouden door SVN opnieuw te maken:
git clean -fd && git svn mkdirs