Projeto

Geral

Perfil

Wiki »

Realizando Commits nos Repositórios dos Projetos

Nesta página são apresentadas algumas orientações e sugestões sobre como commits podem ser realizados nos repositórios. O objetivo é facilitar o procedimento e evitar confusões e enganos no momento da entrega aos repositórios. Para um "primer" sobre o uso do sistema de controle de versões "SVN", tenha como referência a página Criando Repositórios de Trabalho.

O commit é a instrução do SVN para que as alterações, adições e deleções sejam entregues novamente ao repositório em que se está trabalhando, uma vez que os arquivos da cópia local do repositório tenham sido marcados. Entretanto, é importante definir o que deve e o que não deve ser entregue de volta ao repositório: tudo o que foi alterado e modificado e que interfere no funcionamento de um processo.

Por exemplo:

inserção de novas variáveis, comandos, loops, verificações, scripts, namelists, rotinas, processos, procedimentos e outros arquivos (desde que não sejam binários). Se o arquivo que está no repositório possui um caminho absoluto apontando para a conta de um outro usuário, primeiro verifique porque este caminho é absoluto e qual a sua função. Pode acontecer de haver algum script de configuração que altera este caminho e o torna coerente com a instalação do sistema em questão na sua conta de usuário. De fato, isso acontece no projeto SMG no ramo trunk do repositório, na revisão 146 (pode ser que em revisões futuras, esta característica não esteja mais presente). No script "EnvironmentalVariables" do modelo BAM (excerto apresentado a seguir), as variáveis HOMEBASE, SUBTBASE e WORKBASE ajustam os caminhos de instalação e realização do modelo BAM e são "hardwire", apontando para o caminho de um usuário em específico:

#
# Caminhos
#

# Caminho do BAM no HOME
export HOMEBASE=/scratchin/grupos/assim_dados/home/carlos.bastarz/SMG2/cptec/bam

# Caminho do BAM no scratchin (SUBMIT_HOME)
export SUBTBASE=/scratchin/grupos/assim_dados/home/carlos.bastarz/SMG2/datainout/bam

# Caminho do BAM no scratchout (SUBMIT_WORK)
export WORKBASE=/scratchout/grupos/assim_dados/home/carlos.bastarz/SMG2/datainout/bam

Mas acontece que estes caminhos são atualizados durante a execução da função "configurar" do script "config_smg.sh (um script do sistema SMG - Sistema de Modelagem Global), estas variáveis são atualizadas:

  sed -i "/export HOMEBASE=\//,1d" ${home_run_bam}/EnvironmentalVariables
  sed -i "/# Caminho do BAM no HOME/a\export HOMEBASE="${home_bam}"" ${home_run_bam}/EnvironmentalVariables

  sed -i "/export SUBTBASE=\//,1d" ${home_run_bam}/EnvironmentalVariables
  sed -i "/# Caminho do BAM no scratchin (SUBMIT_HOME)/a\export SUBTBASE="${subt_bam}"" ${home_run_bam}/EnvironmentalVariables

  sed -i "/export WORKBASE=\//,1d" ${home_run_bam}/EnvironmentalVariables
  sed -i "/# Caminho do BAM no scratchout (SUBMIT_WORK)/a\export WORKBASE="${work_bam}"" ${home_run_bam}/EnvironmentalVariables

Logo, não se trata de um bug, mas sim uma característica do sistema que pode ser modificada ou melhorada. Lidando com o Redmine, como proceder quando abrir uma tarefa e o que deve ser reportado?

1. Melhorias e procedimentos gerais (tasks)

Caso exista a necessidade de se melhorar esta característica, tornando-a mais genérica (por exemplo), antes de se realizar as modificações e devolvê-las ao repositório, o procedimento deve ser o seguinte: abrir uma tarefa no Redmine e marcá-la como um improvement ou task e informar que será modificado e os motivos. Lembre-se, se o código está funcionando, deve haver um bom motivo para modificá-lo. Caso contrário, deixe como está. Devem haver outras prioridades para a melhoria do sistema.

2. Bugs

Uma outra possibilidade, é quando há bugs que necessitam ser corrigidos. Neste caso, o procedimento deve ser semelhante, com a abertura de uma tarefa no Redmine e esta deve ser marcada como bug. Nesta tarefa devem constar os trechos de código em que foi identificado o problema e os procedimentos realizados quando o problema foi identificado. Não se esqueça de dar informações suficientes para que o problema possa ser reproduzido!

3. Commits

Em qualquer um dos casos, as orientações para se devolver as modificações para o repositório são apresentadas a seguir:

  1. Resolva o problema na sua cópia local:
    Utilize o seu fluxo normal de trabalho. Isso significa que você deve utilizar o seu editor de textos preferido, suas ferramentas de costume etc. Aqui não há novidades.
  2. Realize um export do script/rotina/namelist do repositório com um novo nome:
    Esse procedimento tem por objetivo evitar que você envie modificações desnecessárias de volta ao repositório, portanto, realize as mesmas modificações no passo anterior em uma nova cópia extraída do repositório. Esta nova cópia, deve possuir um nome que permita a você identificar de qual revisão veio o arquivo a ser editado. Como exemplo, considere a revisão fictícia "102" do script de nome "script.sh" do projeto fictício "PROJETO" alocado em "https://svn.cptec.inpe.br/projeto/trunk/PROJETO".
    $ svn export https://svn.cptec.inpe.br/projeto/trunk/PROJETO/scripts/script.sh script.sh.r102
  3. Realize um diff entre a sua cópia local e o script exportado do repositório, a fim de confirmar quais são as alterações que necessitam ser incorporadas a "script.sh.r102":
    $ diff script.sh script.sh.r102
  4. Certifique-se quais são as diferenças que devem ser incorporadas e as introduza no script exportado "script.sh.r102". Faça da forma como lhe convier melhor.
  5. Renomeie a sua cópia local de "script.sh" para "script.sh.local":
    Esse procedimento tem por objetivo preserver a sua cópia local e funcional do script "script.sh".
    $ mv script.sh script.sh.local
  6. Renomeie o script exportado "script.sh.r102" para o nome original da cópia local, isto é, "script.sh":
    Nesta etapa, você vai fazer com que o SVN assuma que o script "script.sh.r102" é a cópia local original. Assim, será possível realizar o commit mais adiante.
    $ mv script.sh.local script.sh
  7. Execute o comando svn diff para se certificar das alterações realizadas (devem refletir estritamente o que foi alterado):
    Este passo é uma espécie de "sanity check" e você deve ter certeza de que o que deve ser devolvido ao repositório é simplesmente o que foi alterado.
    $ svn diff script.sh
  8. Realize o commit apontando o(s) nome(s) e path(s) do(s) script(s) modificados:
    Esta é a parte crítica, pois é importante que você indique onde estão os arquivos a serem devolvidos ao repositório. Se você digitar simplesmente "svn ci" sem especificar os arquivos, vai acabar devolvendo ao repositório vários outros arquivos que foram modificados durante o processo de configuração do sistema.
    $ svn ci ./scripts/script.sh
  9. Após o commit, você pode voltar para o seu script original:
    Isso significa que, uma vez realizado o commit, já não será mais necessária a cópia exportada "script.sh.r102" (e que havia sido renomeada para "script.sh" para a realização do commit).
    $ mv script.sh.local script.sh

Ao final do procedimento, deverá haver apenas a sua cópia local original.

Caso vários scripts, rotinas ou demais arquivos tenham sido modificados e - considerando que todos foram exportados e nomeados conforme as convenções listadas acima, pode ser que você precise procurar pelos arquivos exportados e que foram modificados. Para fazer isso, utilize o comando "find" para procurá-los, e os resultados deste comando indicarão exatamente os arquivos e os seus respectivos paths:

$ find . -name "*.r102" 
./path1/script1.sh
./path2/namelist
./path3/rotina.f90
./path4/script.sh

Neste caso, ao realizar o commit das modificações, não se esqueça de indicar o caminho completo de cada arquivo:

$ svn ci ./path1/script1.sh ./path2/namelist ./path3/rotina.f90 ./path4/script.sh

Dessa forma, não haverá problemas com modificações pessoais que não deveriam constar no repositório e serão apenas entregue ao repositórios os arquivos necessários.