Criando Repositórios de Trabalho¶
- Criando Repositórios de Trabalho
- 1. Criando pastas dentro do repositório
- 2. Importando um projeto/código para dentro do repositório
- 3. Iniciando o trabalho com o controle de versões
- 4. Criando ramificações (branches) do seu projeto
- 5. Fazendo um merge entre dois ramos dentro de um mesmo repositório
- 6. Forçando Atualização para a Última Revisão
- 7. Criando e aplicando Patches
1. Criando pastas dentro do repositório¶
Para criar uma estrutura dentro do repositório do projeto e que possa ser utilizada como repositório de trabalho, basta seguir os procedimentos abaixo:
- Listar o repositório e verificar o seu conteúdo (observar que "projeto" é o nome do projeto em que se está trabalhando):
$ svn list https://svn.cptec.inpe.br/projeto
- Escolher um nome para o repositório: dá-se a sugestão de se nomear o repositório com as iniciais dos dois primeiros nomes seguidos do sobrenome. Exemplo: Nome do usuário - Fulano Ciclano Beltrano; Nome do repositório: fcbeltrano
- Criar o repositório:
$ svn mkdir https://svn.cptec.inpe.br/projeto/fcbeltrano -m "Repositório pessoal de Fulano Ciclano Beltrano"
- Listar novamente a raiz do repositório e verificar se a pasta foi criada:
$ svn list https://svn.cptec.inpe.br/projeto
- Criar os ramos "trunk", "branches" e "tags". Esta etapa é opcional, mas os três ramos ajudam na organização e desenvolvimento do conteúdo do repositório:
$ svn mkdir https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk -m "Ramo de desenvolvimentos principal" $ svn mkdir https://svn.cptec.inpe.br/projeto/fcbeltrano/branches -m "Ramo de desenvolvimentos paralelo" $ svn mkdir https://svn.cptec.inpe.br/projeto/fcbeltrano/tags -m "Ramo de versões de lançamento"
- Listar novamente o conteúdo do repositório criado e verificar se os ramos foram criados corretamente.
$ svn list https://svn.cptec.inpe.br/projeto/fcbeltrano
Com estes passos, já é possível importar um projeto/código que se tenha interessa em versionar.
2. Importando um projeto/código para dentro do repositório¶
Para importar um projeto/código e iniciar o versionamento, basta seguir os procedimentos abaixo:
Na máquina local (onde o projeto/código está), utilizar o comando import do svn. Segue-se o exemplo do projeto (um conjunto de arquivos, pastas e subpastas) de nome PROJETO:
$ ls -l $ PROJETO $ svn import PROJETO https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk/PROJETO -m "Versão inicial de desenvolvimentos de PROJETO"
Com isto, já se tem um projeto sendo versionado pelo SVN e que pode ser visualizado através do Redmine.
2.1 Copiando uma revisão anterior do trunck para um branch de desenvolvimento¶
Em muito casos é bastante util voltar a versão qualquer para uma revisão anterior em algum ponto de seu desenvolvimento para fazer ajustes ou testar modificações naquela versão do código. Para importar um projeto/código de uma versão anterior qualquer e dessa avançar com o versionamento, basta seguir os procedimentos abaixo. Neles recomenda-se criar um tarefa associada a esse desenvolvimento, no caso foi a tarefa 30, e criar um branch dessa tarefa com a revisao 50 do trunch e depois baixar para a máquina local para o desenvolvimento. Para isso faça:
$ ls -l $ svn copy https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk/PROJETO -r50 https://svn.cptec.inpe.br/projeto/fcbeltrano/branch/PROJETO.task30 -m "Copiando o trunk na revisão 50 para o branch associado a tarefa 30" $ svn co https://svn.cptec.inpe.br/projeto/fcbeltrano/branch/PROJETO.task30 -m "Obtendo o branch da tarefa 30 para a maquina local para desenvolvimentos no PROJETO"
3. Iniciando o trabalho com o controle de versões¶
Depois que o projeto foi submetido ao SVN, para que o uso efetivo do sistema de versionamento tenha efeito, deve-se seguir o seguinte roteiro:
- Criar uma cópia de trabalho (cópia local) do projeto versionado
- Fazer os desenvolvimentos/modificações
- Submeter as modificações de volta ao repositório
Cada um destas etapas é bastante importante para que o uso do repositório criado auxilie o desenvolvedor na criação/desenvolvimento/manutenção dos seus projetos. A seguir, é dado um breve detalhamento sobre cada uma destas etapas.
3.1 Cópia de trabalho¶
A cópia de trabalho é uma cópia fiel do que foi submetido ao repositório para o sistema de versionamento. A primeira cópia, ou melhor, o projeto ou conjunto de códigos que foi utilizado para enviar ao sistema de versionamento, é diferente de uma cópia de trabalho. A cópia de trabalho contém informações sobre a revisão (um número único atribuído a cada atividade dentro do repositório, seja ela de importação, cópia, remoção, merge etc), a origem (de qual ramo do repositório veio). Todas as informações que compõem a identidade do código versionado, são indexadas para todos os arquivos componentes de um projeto e são armazenadas em um pasta oculta "svn (.svn), que está presente em todas as pastas e subpastas do projeto. O comando para se criar uma cópia de trabalho na máquina local (onde o código poderá ser modificado e testado) é o "checkout":
$ svn checkout https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk/PROJETO
Este comando irá criar uma pasta de nome PROJETO na sua área de trabalho. De forma similar, se for da necessidade do usuário criar uma pasta de nome diferente para a cópia de trabalho, pode-se utilizar o mesmo comando acima indicando o nome diferente:
$ svn checkout https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk/PROJETO PROJETO.trunk
Seguramente, antes que esta operação de "retirada" (quando se obtém uma cópia de um código/projeto do repositório), pode-se remover a cópia local que foi utilizada para enviar o projeto ao sistema de controle de versões.
Dentro da pasta PROJETO ou PROJETO.trunk criada com o checkout, constará a existência da pasta .svn.
De forma similar ao comando checkout, pode-se aplicar o comando "export". O comando export também realiza uma retirada do repositório com a diferença de que a cópia local não é uma cópia de trabalho, no sentido de que as modificações não poderão ser enviadas de volta ao repositório. De forma geral, a retirada com o comando export gera uma cópia fiel e funcional do código do repositório, mas não permite o controle de versões. Este comando é ideal nas situações em que o usuário deseja apenas experimentar ou realizar um teste do código do projeto versionado.
Caso seja necessário, o usuário ainda pode realizar uma retirada do repositório utilizando uma versão específica. Estas situações podem ocorrer quando o usuário quiser voltar uma ou mais revisões nos seus desenvolvimentos:
$ svn checkout -rXXX https://svn.cptec.inpe.br/projeto/fcbeltrano/trunk/PROJETO PROJETO.trunk
Onde "XXX" representa um número de revisão.
3.2 Modificações e metodologias de desenvolvimento¶
Com a cópia de trabalho criada, chega o momento em que as modificações podem ser realizadas. Esta parte do desenvolvimento do projeto é bastante crítica levando-se em consideração que há metodologias bastante diferentes para isso. Os testes também são bastante importantes porque é através deles que as modificações podem ser testadas e aprovadas para a entrega ao repositório. Em um ambiente de desenvolvimento colaborativo, os métodos e as métricas de desenvolvimento e avaliação devem der discutidas e estabelecidas para que o desenvolvimento seja ordenado e linear.
3.3 Entrega dos desenvolvimentos e modificações¶
Feitas as modificações de acordo com os critérios e metodologias estabelecidas pelo grupo de desenvolvimentos, pode-se fazer a entrega. A entrega é a parte da volta no ciclo de desenvolvimentos utilizando-se um sistema de controle de versões. O comando que permite que isto seja realizado, é o "commit":
$ svn commit -m "Descrição das alterações realizadas e outras observações pertinentes."
O modificador "m" depois da instrução "commit" do comando svn, indica uma mensagem. Esta mensagem é bastante importante pois deverá descrever o resumo das alterações e irá incrementar o log do repositório. Se este modificador não for passado junto com a linha de comando do svn, assim que for pressionada a tecla enter, será aberto um editor de texto (geralmente o "vi", dependendo do valor da variável $EDITOR do seu ambiente) para que a descrição das alterações possa ser digitada. Além disso, é informado o nome dos arquivos que foram alterados, facilitando lembrar quais arquivos foram alterados.
À medida em que as modificações forem realizadas e testadas, é importante entregar as modificações de volta ao repositório. A frequência com que isto deve ser feito dependerá da frequência das modificações e dos testes. O ideal é que, sempre que uma modificação for feita e esta tenha sido testada e aprovada, faça-se um commit.
Com isso, as modificações estarão incorporadas ao repositório criando uma nova revisão, para a qual é atribuída um número distinto. Na página Realizando Commits nos Repositórios são apresentados exemplos e algumas sugestões sobre como os commits nos ramos dos projetos podem ser realizados durante as rotinas de desenvolvimento.
3.4 Adicionando ou Removendo arquivos do repositório¶
Frequentemente será necessário, por razões diversas, adicionar um novo arquivo ou pasta ao seu projeto. Cria-se, portanto os arquivos necessários como em qualquer situação e após isto, deve-se utilizar o comando "add" do SVN para marcar os arquivos ou pastas que devem ser adicionados ao repositório. O próximo passo, é realizar um commit para que os arquivos ou pastas sejam efetivamente adicionados ao repositório. Em sequência, este procedimento seria como abaixo:
Criação/adição de arquivo(s) ou pasta(s) - a partir de uma cópia local:
$ svn add arquivo1 arquivo2 pasta1/ pasta2/
Com isto, os arquivo serão marcados com a letra "A" (de Adicionado).
Commit (entrega) dos arquivos marcados/modificados para o repositório:
$ svn commit
Opcionalmente, pode-se utilizar a opção "-m" (sem aspas) para digitar um breve resumo das modificações, ao invés de se utilizar um simples "svn commit":
$ svn commit -m "Adição dos arquivos arquivo1 e arquivo2 e das pastas pasta1/ e pasta2/"
De forma semelhante ao comando add, há o comando "delete", que marca os arquivos que deverão ser removidos do repositório no próximo commit.
Remoção de arquivo(s) ou pasta(s) - a partir de uma cópia local:
$ svn delete arquivo1 arquivo2 pasta1/ pasta2/
Com isto, os arquivo serão marcados com a letra "D" (de Deletado).
Commit (entrega) dos arquivos marcados/modificados para o repositório:
$ svn commit
Opcionalmente, pode-se utilizar a opção "-m" (sem aspas) para digitar um breve resumo das modificações, ao invés de se utilizar um simples "svn commit":
$ svn commit -m "Adição dos arquivos arquivo1 e arquivo2 e das pastas pasta1/ e pasta2/"
Embora seja bastante prático, a utilização da opção -m pode ser suprimida para que seja possível utilizar o editor (que é aberto automaticamente após pressionar a tecla ENTER) e ver quais arquivos foram modificados, deletados ou adicionados.
Para todos os casos, o comando status do SVN lista e mostra qual é a situação dos arquivos no repositório, se estão marcados como "M" (de Modificados), "A" (de Adicionados), "D" (de Deletados) etc.
4. Criando ramificações (branches) do seu projeto¶
Sempre que se fizer necessária a implementação de uma nova característica, a correção de bug ou o desenvolvimento de alguma atividade que inclua a modificação do código, deve-se criar um branch de desenvolvimentos. O branch tem a função de abrigar uma cópia do projeto que será desenvolvida paralelamte ao código presente no ramo principal trunk. Além, disso, o branch é o espaço ideal para que o desenvolvedor aplique suas idéias e testes sem correr o risco de quebrar o código principal do trunk. Ainda mais, é possível reverter alterações que não deram certo e voltar à revisão funcional do código.
O comando svn para criar um branch a partir do código do trunk, é o "copy". Segue-se os procedimentos abaixo:
$ svn copy https://svn.cptec.inpe.br/projeto/usuario/trunk/PROJETO https://svn.cptec.inpe.br/projeto/usuario/branches/identificador/PROJETO -m "Criação do branch atribuído à tarefa #identificador"
A criação de um branch de desenvolvimentos é simplesmente uma cópia fiel do código do projeto que está no trunk para o branch a ser criado. Após a criação do branch, a primeira tarefa a ser realizada é o checkout do código que está no branch para a sua área de trabalho, criando então, uma cópia de trabalho:
$ svn checkout https://svn.cptec.inpe.br/projeto/usuario/branches/identificador/PROJETO PROJETO
Após este procedimento, as etapas de modificações e entrega (commit) seguem como discutido anteriormente.
5. Fazendo um merge entre dois ramos dentro de um mesmo repositório¶
Além dos comandos "checkout", "export", "commit", "list", "update" e "info", outro comando svn bastante útil é o comando "merge". Como a própria tradução do nome sugere, o merge mescla, combina duas revisões diferentes (ou mesmo dois ramos diferentes, que contém nada mais além do que revisões diferentes do código de um mesmo projeto). Em conjunto com o comando merge, há o comando "switch" (troca), que permite alterar o ramo do repositório em que se encontra. Como exemplo, pode-se realizar um merge entre o código de PROJETO no ramo trunk com o código de PROJETO no ramo branch. Para isso, segue-se os passos abaixo:
- Checkout do código do ramo branch (destino, onde as modificações do trunk serão incorporadas):
$ svn checkout https://svn.cptec.inpe.br/projeto/usuario/branch/PROJETO PROJETO.branch
- Entrar na pasta PROJETO.branch, criada durante o checkout:
$ cd PROJETO.branch
- Merge entre o trunk e o branch do repositório:
$ svn merge https://svn.cptec.inpe.br/projeto/usuario/trunk/PROJETO .
Com o merge, todos os arquivos que foram adicionado, alterados ou deletados serão marcados para o commit, que finalmente criará uma nova revisão resultante da operação de merge.
No exemplo acima, todas as suas modificações feitas no seu branch serão preservadas. Apenas as atualizações feitas no trunk serão trazidas para o seu branch.
Utilizar o comando status para verificar quais arquivos foram alterados:
$ svn status
Para verificar apenas os arquivos que foram modificados:
$ svn status | grep ^M
Commit das alterações:
$ svn ci
Por fim, basta digitar as alterações no editor de textos (eg., vi). Todos os arquivos marcados com alguma alteração, são enviados de volta ao repositório.
6. Forçando Atualização para a Última Revisão¶
Em algumas situações pode ser necessário forçar a atualização da sua cópia local para a última revisão HEAD do repositório em que você estiver trabalhando. Isso pode acontecer porque os arquivos que você modificou serão atualizados apenas dentro da sua revisão BASE. Para forçar a atualização para a revisão HEAD do repositório, bastam dois comandos:
- Reverter as modificações realizadas para o estado original da revisão da sua cópia local:
$ svn revert -R .
Obs.: Observe que se está indicando os modificadores "-R .", indicando que o comando será executado recursivamente a partir do diretório corrente. - Aplicar o update para a revisão HEAD do repositório:
$ svn update
7. Criando e aplicando Patches¶
Durante o desenvolvimento do seu projeto, em alguma ocasiões poderá ser útil criar um "patch" das alterações que você fez para que possam ser incorporadas em uma outra revisão do seu projeto. Um patch, por definição, é um arquivo texto que contém informações sobre as alterações feitas em um ou mais arquivos. Estas informações incluem o nome do arquivo, a linha e a alteração. Para criar um patch com as alterações de um projeto, basta utilizar o comando svn diff dentro da sua cópia local:
$ cd <copia_local> $ svn diff > ~/arquivo_com_diferencas.patch
Observação: é possível substituir o comando diff do svn pelo comando diff que estiver instalado na máquina. A vantagem está na possibilidade de se utilizar os recursos do comando, como no exemplo abaixo em que são ignorados arquivos binários:
$ svn diff --force --diff-cmd /usr/bin/diff -x "-au --binary" > ~/arquivo_com_diferencas.patch
Utilizando-se o redirecionador (sinal de maior), é criado o arquivo arquivo_com_diferencas.patch na pasta $HOME do usuário. A extensão ".patch" não é obrigatória, mas para efeito de organização, recomenda-se o seu uso. O conteúdo do arquivo criado é semelhante a:
--- run/run_cycle.sh (revision 229)
+++ run/run_cycle.sh (working copy)
@@ -38,7 +38,7 @@
# Verificando argumentos de entrada
#
if [ -z "${1}" ];then
- export LABELI=2004010100
+ export LABELI=2004010106
else
export LABELI=${1}
fi
Observe que no arquivo são dadas as informações da cópia de origem (a revisão que está no repositório) com o sinal de "-" e da cópia local que foi alterada, com o sinal de "+". A seguir, é anunciada a linha referente à modificação e, em seguida, a modificação (assinalada com um sinal de "+"). Blocos grandes de alterações, conterão várias linhas com sinais de "+" e de "-".
Depois que o arquivo de patch é criado, pode-se aplicá-lo à uma outra cópia local do projeto ou arquivo (rotina, script etc) em questão. Para isto, utiliza-se o comando patch (nativo do Linux):
$ cd <outra_copia_local> $ patch -p0 -i ~/arquivo_com_diferencas.patch
No comando acima, a opção "-p0" assegura que o caminho completo para o arquivo de diferenças (patch) será mantido - esta é uma peculiaridade do patch (para mais informações, digite man patch no terminal). A opção "-i" indica um arquivo de entrada, no caso, o arquivo de diferenças a ser aplicado.
Exemplo de saída da aplicação de um patch:
$ patch -p0 -i ../tag-v1.1.2_g3dvar.patch patching file config_g3dvar.ksh patching file run/scripts/run_gsi.sh patching file run/scripts/run_interface.sh patching file run/scripts/run_model.sh patching file run/scripts/agcm_scripts/README patching file run/scripts/run_obsmake.sh patching file run/run_cycle.sh patching file EVENTS patching file docs/README patching file VARIAVEIS patching file cptec/gsi/SRC/GSIsa/Linux/Config/NCEP_base.mk patching file cptec/gsi/SRC/GSIsa/Linux/etc/BASEDIR.rc patching file cptec/agcm/model/source/Diagnostics.f90 patching file cptec/agcm/model/source/Makefile patching file cptec/agcm/model/source/GridDynamics.f90 patching file cptec/agcm/model/source/Constants.f90.in patching file cptec/agcm/model/source/Surface.f90 patching file cptec/agcm/model/source/PhysicalFunctions.f90 patching file cptec/agcm/model/source/Constants.f90 patching file cptec/agcm/pos/source/Conversion.f90 patching file cptec/agcm/pos/source/POSTIN-GRIB patching file cptec/agcm/pos/source/FileAccess.f90 patching file cptec/agcm/pos/source/PostLoop.f90 patching file cptec/agcm/pos/source/FileGrib.f90 patching file cptec/agcm/pos/source/PrblSize.f90 patching file cptec/agcm/pos/source/mod_tables.f90 patching file cptec/agcm/pos/source/Constants.f90 patching file cptec/agcm/run/EnvironmentalVariablesMCGA patching file cptec/agcm/run/runModel patching file cptec/agcm/run/runPos patching file cptec/agcm/run/runPre patching file cptec/agcm/run/POSTIN-GRIB patching file cptec/agcm/README patching file cptec/etc/BASEDIR.rc
Aplicado o patch, é importante executar o comando svn status para verificar a situação dos arquivos locais. Segue um exemplo a seguir:
$ svn status M . M config_g3dvar.ksh M run/scripts/run_gsi.sh M run/scripts/run_interface.sh M run/scripts/run_model.sh M run/scripts/agcm_scripts/README M run/scripts/run_obsmake.sh M run/run_cycle.sh D EVENTS D config M docs/README M VARIAVEIS M cptec/gsi/SRC/GSIsa/Linux/Config/NCEP_base.mk D cptec/gsi/SRC/GSIsa/Linux/bin/reblock D cptec/gsi/SRC/GSIsa/Linux/bin/block D cptec/gsi/SRC/GSIsa/Linux/bin/unblock M cptec/gsi/SRC/GSIsa/Linux/etc/BASEDIR.rc D cptec/gsi/SRC/GSIsa/src/Applications/NCEP_Paqc/block-unblock/reblock D cptec/gsi/SRC/GSIsa/src/Applications/NCEP_Paqc/block-unblock/block D cptec/gsi/SRC/GSIsa/src/Applications/NCEP_Paqc/block-unblock/unblock M cptec/agcm/model/source/Diagnostics.f90 M cptec/agcm/model/source/Makefile M cptec/agcm/model/source/GridDynamics.f90 M cptec/agcm/model/source/Constants.f90.in M cptec/agcm/model/source/Surface.f90 M cptec/agcm/model/source/PhysicalFunctions.f90 M cptec/agcm/model/source/Constants.f90 A + cptec/agcm/model/datain A + cptec/agcm/model/datain/SoilChar_IBIS.Tab A + cptec/agcm/model/datain/UnitsConvFactor1Table A + cptec/agcm/model/datain/GridHistLocations.G00576 A + cptec/agcm/model/datain/UnitsConvFactor2Table A + cptec/agcm/model/datain/sp_sw_hadgem1_3r A + cptec/agcm/model/datain/GridHistDesiredTable A + cptec/agcm/model/datain/ocnalbtab24bnd.bin A + cptec/agcm/model/datain/DiagDesiredTable.clm A + cptec/agcm/model/datain/GridHistAvailableTable A + cptec/agcm/model/datain/Morph.Tab A + cptec/agcm/model/datain/sp_lw_hadgem1_3 A + cptec/agcm/model/datain/Units A + cptec/agcm/model/datain/GridHistLocations.G00320 A + cptec/agcm/model/datain/UnitsLookUpTable A + cptec/agcm/model/datain/AeroVar.Tab A + cptec/agcm/model/datain/GridHistLocations.G00062 A + cptec/agcm/model/datain/GridHistLocations.G00064 A + cptec/agcm/model/datain/SoilChar.Tab A + cptec/agcm/model/datain/DiagDesiredTable.pnt A + cptec/agcm/model/datain/DiagDesiredTable A + cptec/agcm/model/datain/BioChar.Tab A + cptec/agcm/model/datain/GridHistLocations.G00096 A + cptec/agcm/model/datain/DiagAvailableTable M cptec/agcm/pos/source/Conversion.f90 M cptec/agcm/pos/source/POSTIN-GRIB M cptec/agcm/pos/source/FileAccess.f90 M cptec/agcm/pos/source/PostLoop.f90 M cptec/agcm/pos/source/FileGrib.f90 M cptec/agcm/pos/source/PrblSize.f90 M cptec/agcm/pos/source/mod_tables.f90 M cptec/agcm/pos/source/Constants.f90 A + cptec/agcm/pos/datain A + cptec/agcm/pos/datain/tab1_pnt.dat A + cptec/agcm/pos/datain/tab2_pnt.dat A + cptec/agcm/pos/datain/tab3_pnt.dat A + cptec/agcm/pos/datain/rfd.eta A + cptec/agcm/pos/datain/rfd.clm A + cptec/agcm/pos/datain/rfd.sfc A + cptec/agcm/pos/datain/tab1_eta.dat A + cptec/agcm/pos/datain/tab2_eta.dat A + cptec/agcm/pos/datain/tab3_eta.dat A + cptec/agcm/pos/datain/tab1_clm.dat A + cptec/agcm/pos/datain/tab1_sfc.dat A + cptec/agcm/pos/datain/tab2_sfc.dat A + cptec/agcm/pos/datain/tab2_clm.dat A + cptec/agcm/pos/datain/tab3_sfc.dat A + cptec/agcm/pos/datain/tab3_clm.dat A + cptec/agcm/pos/datain/tab1.dat A + cptec/agcm/pos/datain/tab2.dat A + cptec/agcm/pos/datain/rfd.ens A + cptec/agcm/pos/datain/tab3.dat A + cptec/agcm/pos/datain/tab1_ens.dat A + cptec/agcm/pos/datain/tab2_ens.dat A + cptec/agcm/pos/datain/tab3_ens.dat A + cptec/agcm/pos/datain/rfd.pnt A + cptec/agcm/pos/datain/rfd A + cptec/agcm/pos/datain/dft M cptec/agcm/run/EnvironmentalVariablesMCGA M cptec/agcm/run/runModel M cptec/agcm/run/runPos M cptec/agcm/run/runPre M cptec/agcm/run/POSTIN-GRIB M cptec/agcm/README D cptec/bin/reblock D cptec/bin/inctime D cptec/bin/block D cptec/bin/unblock D cptec/bin/cwordsh.o M cptec/etc/BASEDIR.rc
Observe que há arquivos que foram adicionados (A +), atualizados (U), modificados (M) e deletados (D). Quando o comando svn commit for executado, estas alterações serão enviadas de volta ao repositório.
Para uma explicação diferente e ilustrada dos comandos patch e diff, assista a uma vídeo-aula aqui.