Skip to content

Latest commit

 

History

History
491 lines (390 loc) · 35.8 KB

client-svn.asc

File metadata and controls

491 lines (390 loc) · 35.8 KB

Гит и Subversion

Велики део развојних пројеката отвореног кода и порпиличан број корпоративних пројеката користе Subversion да управља њиховим изворним кодом. Присутан је већ више од десет година и већину тог времена је био де факто VCS избор за пројекте отвореног кода. У многим стварима је врло сличан са CVS који је пре тога био татамата света контроле изворног кода.

Једна од одличних могућности програма Гит је двосмерни мост према програму Subversion који се зове git svn. Овај алат вам омогућава да програм Гит користите као важећи клијент Subversion сервера, тако да можете користити све локалне могућности програма Гит и да их затим гурнете на Subversion сервер као да се и локално користили Subversion. Ово значи да можете радити локално гранање и спајање, користите стејџ, употребљавате ребазирање и избор (cherry-picking) и тако даље, док ваши сарадници настављају да раде на своје мрачне прастаре начине. То је добар начин да провучете програм Гит у корпоративно окружење и помогнете да ваше колеге програмери постану ефикаснији док ви лобирате да се инфраструктура промени тако да у потпуности подржава програм Гит. Subversion мост је уводна дрога у DVCS свет.

git svn

Основна команда у програму Гит за све команде премошћавања до Subversion је git svn. Постоји поприличан број команди, тако да ћемо приказати најчешће док пролазимо кроз неколико једноставних процеса рада.

Важно је приметити да када користите git svn, ви имате интеракцију са програмом Subversion, а то је систем који функционише веома различито у односу на програм Гит. Мада можете да радите локално гранање и спајање, у општем случају је најбоље да историју држите што је могуће више линеарном тако што ребазирате свој рад и избегавате да радите ствари као што је истовремена интеракција са удаљеним Гит репозиторијумом.

Немојте поново да исписујете своју историју и покушате поново да је гурнете и немојте да истовремено гурате на паралелни Гит репозиторијум како би сарађивали са колегама који за развој користе Гит. Subversion може да има са једну линеарну историју, и врло је једноставно да га збуните. Ако радите у тиму где неко користи SVN, а остали користе Гит, обезбедите да сви за сарадњу користе SVN сервер – на тај начин ће вам живот бити једноставнији.

Подешавање

Да бисте пробали ову функционалност, потребан вам је типичан SVN репозиторијум на који има те право уписа. Ако желите да копирате ове примере, мораћете да направите копију мог тест репозиторијума по којој можете да пишете. То једноставно можете урадити алатом који се зове svnsync и долази уз програм Subversion. Као подршку овим тестовима, направили смо нови Subversion репозиторијум на Google Code који је представљао делимичну копију пројекта protobuf, алата који кодира структуре података тако да могу да се преносе кроз мрежу.

Да бисте успешно пратили, најпре морате да креирате нови локални Subversion репозиторијум:

$ mkdir /tmp/test-svn
$ svnadmin create /tmp/test-svn

Затим омогућите свим корисницима право да мењају revprops – то се на једноставан начин ради тако да додате скрипту pre-revprop-change која увек враћа повратну вредност 0:

$ cat /tmp/test-svn/hooks/pre-revprop-change
#!/bin/sh
exit 0;
$ chmod +x /tmp/test-svn/hooks/pre-revprop-change

Овај пројекат сада можете да синхронизујете на своју локалну машину тако што позовете svnsync init са ’из’ и ’у’ репозиторијумима.

$ svnsync init file:///tmp/test-svn \
  http://progit-example.googlecode.com/svn/

Ово поставља особине за позив синхронизације. Затим клонирате кôд извршавајући:

$ svnsync sync file:///tmp/test-svn
Committed revision 1.
Copied properties for revision 1.
Transmitting file data .............................[...]
Committed revision 2.
Copied properties for revision 2.
[…]

Мада ова операција може да потраје само неколико минута, ако уместо на локални оригинални репозиторијум покушате да копирате на други удаљени репозиторијум, процес ће трајати скоро сат времена, мада постоји мање од 100 комитова. Subversion мора да клонира ревизије једну по једну, па да их затим гурне на други репозиторијум – потпуно неефикасно, али је то једини начин да се ово уради.

Први кораци

Сада када имате Subversion репозиторијум у који можете да уписујете, можете да прођете кроз типичан процес рада. Почећете да командом git svn clone која увози комплетан Subversion репозиторијум у локални Гит репозиторијум. Упамтите да ако увозите из реалног хостованог Subversion репозиторијума, фајл file:///tmp/test-svn приказан овде треба да замените са URL адресом вашег Subversion репозиторијума:

$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
Initialized empty Git repository in /private/tmp/progit/test-svn/.git/
r1 = dcbfb5891860124cc2e8cc616cded42624897125 (refs/remotes/origin/trunk)
    A	m4/acx_pthread.m4
    A	m4/stl_hash.m4
    A	java/src/test/java/com/google/protobuf/UnknownFieldSetTest.java
    A	java/src/test/java/com/google/protobuf/WireFormatTest.java
…
r75 = 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae (refs/remotes/origin/trunk)
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/my-calc-branch, 75
Found branch parent: (refs/remotes/origin/my-calc-branch) 556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae
Following parent with do_switch
Successfully followed parent
r76 = 0fb585761df569eaecd8146c71e58d70147460a2 (refs/remotes/origin/my-calc-branch)
Checked out HEAD:
  file:///tmp/test-svn/trunk r75

Ово извршава еквивалент две команде – git svn init након које следи git svn fetch – над URL адресом коју наведете. Може да потраје. Тест пројекат има само око 75 комитова и база кода није толико велика, али програм Гит мора да одјави сваку верзију, једну по једну, па да је засебно комитује. За пројекат са стотинама или хиљадама комитова, ово буквално може да потраје сатима или чак данима док се не заврши.

-T trunk -b branches -t tags део говори програму Гит да овај Subversion репозиторијум прати основне конвенције гранања и означавања. Ако свом стаблу, гранама или ознакама желите да дате другачија имена, промените ове опције. Пошто је ово толико уобичајено, комплетан део можете да замените са -s, што значи стандардни распоред и подразумева све те опције. Следећа команда је еквивалентна:

$ git svn clone file:///tmp/test-svn -s

У овом тренутку би требало да имате исправан Гит репозиторијум које увезао ваше гране и ознаке:

$ git branch -a
* master
  remotes/origin/my-calc-branch
  remotes/origin/tags/2.0.2
  remotes/origin/tags/release-2.0.1
  remotes/origin/tags/release-2.0.2
  remotes/origin/tags/release-2.0.2rc1
  remotes/origin/trunk

Приметите како овај алат управља Subversion ознакама као удаљеним референцама. Хајде да детаљније погледамо водоводном командом програма Гит show-ref:

$ git show-ref
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/heads/master
0fb585761df569eaecd8146c71e58d70147460a2 refs/remotes/origin/my-calc-branch
bfd2d79303166789fc73af4046651a4b35c12f0b refs/remotes/origin/tags/2.0.2
285c2b2e36e467dd4d91c8e3c0c0e1750b3fe8ca refs/remotes/origin/tags/release-2.0.1
cbda99cb45d9abcb9793db1d4f70ae562a969f1e refs/remotes/origin/tags/release-2.0.2
a9f074aa89e826d6f9d30808ce5ae3ffe711feda refs/remotes/origin/tags/release-2.0.2rc1
556a3e1e7ad1fde0a32823fc7e4d046bcfd86dae refs/remotes/origin/trunk

Програм Гит ово не ради када клонира са Гит сервера; ево како изгледа репозиторијум након свежег клонирања:

$ git show-ref
c3dcbe8488c6240392e8a5d7553bbffcb0f94ef0 refs/remotes/origin/master
32ef1d1c7cc8c603ab78416262cc421b80a8c2df refs/remotes/origin/branch-1
75f703a3580a9b81ead89fe1138e6da858c5ba18 refs/remotes/origin/branch-2
23f8588dde934e8f33c263c6d8359b2ae095f863 refs/tags/v0.1.0
7064938bd5e7ef47bfd79a685a62c1e2649e2ce7 refs/tags/v0.2.0
6dcb09b5b57875f334f61aebed695e2e4193db5e refs/tags/v1.0.0

Програм Гит преузима ознаке директно у refs/tags, уместо да их третира као удаљене гране.

Комитовање назад на Subversion

Сада када имате функционалан репозиторијум, можете да урадите неки посао на пројекту и гурнете своје комитове узводно, тако што програм Гит ефективно користите као SVN клијент. Ако уредите један од фајлова и комитујете га, имаћете комит који постоји локално у програму Гит и не постоји на Subversion серверу:

$ git commit -am 'Adding git-svn instructions to the README'
[master 4af61fd] Adding git-svn instructions to the README
 1 file changed, 5 insertions(+)

Затим, своју измену морате да гурнете узводно. Приметите како ово мења начин на који радите са програмом Subversion – можете да урадите неколико комитова док ста ван мреже, па да их све одједном гурнете на Subversion сервер. Када желите да гурнете на Subversion сервер, извршите команду git svn dcommit:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	README.txt
Committed r77
    M	README.txt
r77 = 95e0222ba6399739834380eb10afcd73e0670bc5 (refs/remotes/origin/trunk)
No changes between 4af61fd05045e07598c553167e0f31c84fd6ffe1 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Ово узима све комитове које сте направили преко кода са Subversion сервера, за сваки од њих врши Subversion комит, па онда поново исписује ваш локални Гит комит тако да укључи јединствени идентификатор. То је важно јер значи да се све SHA-1 контролне суме ваших комитова мењају. Делимично због овог разлога, истовремени рад са удаљеним Гит верзијама вашег пројекта и Subversion сервером није добра идеја. Ако погледате последњи комит, можете видети уметнути нови git-svn-id:

$ git log -1
commit 95e0222ba6399739834380eb10afcd73e0670bc5
Author: ben <ben@0b684db3-b064-4277-89d1-21af03df0a68>
Date:   Thu Jul 24 03:08:36 2014 +0000

    Adding git-svn instructions to the README

    git-svn-id: file:///tmp/test-svn/trunk@77 0b684db3-b064-4277-89d1-21af03df0a68

Приметите да је SHA-1 контролна сума када сте раније комитовали почињала са 4af61fd, а да сада почиње са 95e0222. Ако желите да гурнете и на Гит и на Subversion сервер, прво морате да гурнете (dcommit) на Subversion сервер, јер та акција мења ваше комит податке.

Повлачење нових измена

Ако радите са другим програмерима, онда ће у неком тренутку један од вас гурнути, па ће онда неко други покушати да гурне измену која изазива конфликт. Та измена ће бити одбијена док не спојите њихов рад. У git svn то изгледа овако:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...

ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: d5837c4b461b7c0e018b49d12398769d2bfc240a and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 f414c433af0fd6734428cf9d2a9fd8ba00ada145 c80b6127dd04f5fcda218730ddf3a2da4eb39138 M	README.txt
Current branch master is up to date.
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.

Да бисте разрешили ову ситуацију, можете да извршите git svn rebase, која повлачи евентуалне измене на серверу које још увек немате и ребазира ваш рад (ако га има) на врх онога што се налази на серверу:

$ git svn rebase
Committing to file:///tmp/test-svn/trunk ...

ERROR from SVN:
Transaction is out of date: File '/trunk/README.txt' is out of date
W: eaa029d99f87c5c822c5c29039d19111ff32ef46 and refs/remotes/origin/trunk differ, using rebase:
:100644 100644 65536c6e30d263495c17d781962cfff12422693a b34372b25ccf4945fe5658fa381b075045e7702a M	README.txt
First, rewinding head to replay your work on top of it...
Applying: update foo
Using index info to reconstruct a base tree...
M	README.txt
Falling back to patching base and 3-way merge...
Auto-merging README.txt
ERROR: Not all changes have been committed into SVN, however the committed
ones (if any) seem to be successfully integrated into the working tree.
Please see the above messages for details.

Сада је сав ваш рад преко онога што се налази на Subversion серверу, тако да можете успешно извршити dcommit:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	README.txt
Committed r85
    M	README.txt
r85 = 9c29704cc0bbbed7bd58160cfb66cb9191835cd8 (refs/remotes/origin/trunk)
No changes between 5762f56732a958d6cfda681b661d2a239cc53ef5 and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Приметите да за разлику од програма Гит, који од вас захтева да пре него што гурнете спојите сав узводни рад који још увек немате локално, git svn од вас то тражи само ако измене изазивају конфликт (слично као што ради и Subversion). Ако неко други гурне измену једног фајла, панда ви гурнете измену неког другог фајла, ваша dcommit ће функционисати без проблема:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	configure.ac
Committed r87
    M	autogen.sh
r86 = d8450bab8a77228a644b7dc0e95977ffc61adff7 (refs/remotes/origin/trunk)
    M	configure.ac
r87 = f3653ea40cb4e26b6281cec102e35dcba1fe17c4 (refs/remotes/origin/trunk)
W: a0253d06732169107aa020390d9fefd2b1d92806 and refs/remotes/origin/trunk differ, using rebase:
:100755 100755 efa5a59965fbbb5b2b0a12890f1b351bb5493c18 e757b59a9439312d80d5d43bb65d4a7d0389ed6d M	autogen.sh
First, rewinding head to replay your work on top of it...

Ово је важно да се запамти, је крајњи исход стање пројекта које није постојало ни на једном од ваших компјутера када сте гурнули. Ако измене нису компатибилне али не изазивају конфликт, можете имати проблеме који се тешко откривају. То је разлика у односу на употребу Гит сервера – у програму Гит Git стање можете потпуно тестирати на свом клијентском систему пре него што га објавите, док у SVN, никада не можете бити сигурни да су стања непосредно пре и након комита идентична.

Ову команду би такође требало да извршите за повлачење измена са Subversion сервера, чак и ако сами нисте спремни да комитујете. Можете извршити git svn fetch да само преузмете нове податке, али git svn rebase преузима па ажурира ваше локалне комитове.

$ git svn rebase
    M	autogen.sh
r88 = c9c5f83c64bd755368784b444bc7a0216cc1e17b (refs/remotes/origin/trunk)
First, rewinding head to replay your work on top of it...
Fast-forwarded master to refs/remotes/origin/trunk.

Повремено извршавање git svn rebase обезбеђује да је ваш кôд увек у свежем стању. Ипак, да бисте ово извршили, морате бити сигурни да је ваш радни директоријум чист. Ако имате локалне измене, морате прво или да сакријете свој рад, или да га привремено комитујете пре покретања git svn rebase – у супротном ће команда прекинути извршавање ако види да ће резултат ребазирања изазвати конфликт при спајању.

Проблеми са Гит гранањем

Када вам Гит процес рада постане удобан, вероватно ћете почети да креирате тематске гране, радите на њима, па их спајате у главну. Ако гурате на Subversion сервер командом git svn, уместо да гране спајате могли бисте да свој рад ребазирате на једну грану. Ребазирање је пожељније од спајања јер Subversion има линеарну историју и не носи се са спајањима као што то ради програм Гит, тако да git svn следи само првог родитеља када конвертује снимке у Subversion комитове.

Претпоставимо да вам историја изгледа на следећи начин: креирали сте experiment грану, направили два комита, па их онда спојили назад у master. Када извршите dcommit, добијате следећи излаз:

$ git svn dcommit
Committing to file:///tmp/test-svn/trunk ...
    M	CHANGES.txt
Committed r89
    M	CHANGES.txt
r89 = 89d492c884ea7c834353563d5d913c6adf933981 (refs/remotes/origin/trunk)
    M	COPYING.txt
    M	INSTALL.txt
Committed r90
    M	INSTALL.txt
    M	COPYING.txt
r90 = cb522197870e61467473391799148f6721bcf9a0 (refs/remotes/origin/trunk)
No changes between 71af502c214ba13123992338569f4669877f55fd and refs/remotes/origin/trunk
Resetting to the latest refs/remotes/origin/trunk

Извршавање dcommit на грани са спојеном историјом ради како треба, није поново исписала ниједан од комитова које сте направили на experiment грани – уместо тога, све те измене се појављују у SVN верзији једног јединог комита спајања.

Када неко други клонира тај рад, све што види је комит спајања са комплетним радом сабијеним у њега, као да сте извршили git merge --squash; не види податке о томе одакле је комит дошао или када је направљен.

Subversion гранање

Гранање у програму Subversion није исто као гранање у програму Гит; вероватно је најбоље ако можете избећи да га често користите. Ипак, са git svn можете да креирате и комитујете Subversion гране.

Креирање нове SVN гране

Ако желите да креирате нову Subversion грану, извршите git svn branch [имегране]:

$ git svn branch opera
Copying file:///tmp/test-svn/trunk at r90 to file:///tmp/test-svn/branches/opera...
Found possible branch point: file:///tmp/test-svn/trunk => file:///tmp/test-svn/branches/opera, 90
Found branch parent: (refs/remotes/origin/opera) cb522197870e61467473391799148f6721bcf9a0
Following parent with do_switch
Successfully followed parent
r91 = f1b64a3855d3c8dd84ee0ef10fa89d27f1584302 (refs/remotes/origin/opera)

Ово је еквивалентно Subversion команди svn copy trunk branches/opera и оперише на Subversion серверу. Важно је приметити да она вас она не одјављује у ту грану; ако у овом тренутку комитујете, так комит иде у trunk на серверу, а не у opera.

Пребацивање активних грана

Програм Git открива на коју грану иду ваши dcommit тако што гледа на врх било које Subversion гране у вашој историји – требало би да имате само једну, а то би у исорији тренутне гране требало да буде последња са git-svn-id.

Ако желите истовремено да радите на више од једне гране, команди dcommit можете да подесите локалне гране на одређене Subversion грана започињући их као увезени Subversion комит за ту грану. Ако желите грану opera на којој можете одвојено да радите, извршите:

$ git branch opera remotes/origin/opera

Ако сада желите да своју opera грану спојите у trunk (односно вашу master грану), то можете урадити обичном git merge командом. Али морате навести описну комит поруку (са -m), или ће спајање уместо нечег корисниг да буде „Merge branch opera”.

Упамтите да мада за ову операцију користите git merge и спајање ће вероватно бити доста једноставније него што би било у програму Subversion (јер ће програм Гит аутоматски за вас да открије погодну базу за спајање), ово није уобичајен Гит комит спајања. Ове податке морате да гурнете назад Subversion серверу који не може да обради комит који прати више од једног родитеља; дакле, након што га гурнете узводно, изгледаће као један једини комит који је сабио сав рад на другој грани у један комит. Када једну грану спојите у другу, можете једноставно да се вратите назад и наставите да радите на тој грани, као и иначе што бисте у програму Гит. Команда dcommit коју извршавате брише било какве информације које кажу која грана је спојена, тако да ће накнадна израчунавања базе спајања вити погрешна – dcommit чини да резултат ваше git merge команде изгледа као да се извршили git merge --squash. Нажалост, не постоји добар начин да се избегне оваква ситуација – Subversion не може да забележи ову информацију, тако да ће вас увек спутавати његова ограничења док год га користите као свој сервер. Да бисте спречили проблеме, када је спојите у trunk требало би да обришете локалну грану (у овом случају, opera).

Subversion команде

git svn скуп алата обезбеђује већи број команди које помажу да се олакша прелаз на Гит нудећи неку функционалност која је слична оној коју имате у програму Subversion. Ево неколико команди које вам пружају оно што је Subversion.

Историја у SVN стилу

Ако сте навикли на Subversion и своју историју желите да видите као излаз у SVN стилу, you можете да извршите git svn log која вам приказује SVN форматирану комит историју:

$ git svn log
------------------------------------------------------------------------
r87 | schacon | 2014-05-02 16:07:37 -0700 (Sat, 02 May 2014) | 2 lines

autogen change

------------------------------------------------------------------------
r86 | schacon | 2014-05-02 16:00:21 -0700 (Sat, 02 May 2014) | 2 lines

Merge branch 'experiment'

------------------------------------------------------------------------
r85 | schacon | 2014-05-02 16:00:09 -0700 (Sat, 02 May 2014) | 2 lines

updated the changelog

Требало би да знате две важне ствари у вези команде git svn log. Прво, она за разлику од праве svn log команде која тражи податке од Subversion сервера тражи податке, ради ван мреже. Друго, она вам приказује само оне комитове који су комитовани на Subversion сервер. Локални Фит комитови над којима још нисте извршили dcommit се не појављују; као ни комитови које су у међувремену остали доставили на Subversion сервер. Она пре приказује последње познато стање комитова на Subversion серверу.

SVN означавање

На сличан начин на који git svn log команда симулира svn log команду ван мреже, еквивалент команде svn annotate можете добити извршавањем git svn blame [ФАЈЛ]. Излаз изгледа овако:

$ git svn blame README.txt
 2   temporal Protocol Buffers - Google's data interchange format
 2   temporal Copyright 2008 Google Inc.
 2   temporal http://code.google.com/apis/protocolbuffers/
 2   temporal
22   temporal C++ Installation - Unix
22   temporal =======================
 2   temporal
79    schacon Committing in git-svn.
78    schacon
 2   temporal To build and install the C++ Protocol Buffer runtime and the Protocol
 2   temporal Buffer compiler (protoc) execute the following:
 2   temporal

Опет, она не приказује комитове које сте локално направили у програму Гит, или оне који су у међувремену гурнути на Subversion сервер.

Информације о SVN серверу

Исту врсту информација које вам пружа svn info можете добити ако извршите git svn info:

$ git svn info
Path: .
URL: https://schacon-test.googlecode.com/svn/trunk
Repository Root: https://schacon-test.googlecode.com/svn
Repository UUID: 4c93b258-373f-11de-be05-5f7a86268029
Revision: 87
Node Kind: directory
Schedule: normal
Last Changed Author: schacon
Last Changed Rev: 87
Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)

Ово је слично са blame и log у томе што се извршава ван мреже и што је ажурно само до последњег тренутка када сте имали комуникацију са Subversion сервером.

Игнорисање онога што игнорише Subversion

Ако клонирате Subversion репозиторијум који негде има постављене svn:ignore особине, вероватно ћете хтети да поставите одговарајуће .gitignore фајлове тако да случајно не комитујете фајлове које не би требало. git svn има две команде које вам помажу у томе. Прва је git svn create-ignore, која уместо вас аутоматски креира одговарајуће .gitignore фајлове тако да ваш наредни комит не може да их укључи.

Друга команда је git svn show-ignore, која на stdout исписује линије које треба поставите у .gitignore фајл, тако њен излаз можете да преусмерите у фајл изузетака пројекта:

$ git svn show-ignore > .git/info/exclude

На тај начин не затрпавате пројекат .gitignore фајловима. Ово је добра опција у случају да сте једини Гит корисник у Subversion тиму и ваше колеге из тима не желе .gitignore фајлове у пројекту.

Git-Svn резиме

git svn алату су корисни ако сте заглављени на Subversion серверу, или у неком развојном окружењу у којем је неопходно покретање Subversion сервера. Ипак, требало би да га сматрате ограниченим програмом Гит, или ћете наићи на проблеме у превођењу коју могу да збуне и вас и ваше сараднике. Покушајте се држати следећих смерница како не бисте упали у невоље:

  • Одржавајте линеарну Гит историју која не садржи git merge комитове спајања. Ребазирајте сав рад који радите ван главне гране назад на њу; не спајајте у главну грану.

  • Не постављате и не сарађујте на одвојеном Гит серверу. По могућству имајте један који убрзава клонирања за нове програмере, али не гурајте на њега ништа што нема git-svn-id ставку. Чак можете да додате и pre-receive куку која проверава сваку комит поруку на постојање git-svn-id и одбија гурања које садрже комит поруке без ње.

Ако следите ове препоруке, рад са Subversion сервером може постати подношљив. Међутим, ако постоји могућност, пређите на прави Гит сервер, на тај начин ћете и ви и тим добити још много више.