| | 21 | == Fechamento de Tickets == |
| | 22 | |
| | 23 | O fechamento deve ser feito via de regra somente após o ''commit'' no svn, pois será necessário o número da revisão do repositório para que a amarração entre o trac e o svn seja feita corretamente. Sendo assim devem ser utilizadas as frases reservadas "Implementado em" ou "Corrigido em". Implementado em indica o fechamento do ticket. Corrigido em indica a correção de um ticket que foi fechado e depois reaberto decorrente de algum problema no seu fechamento. Seguido da frase reservada deve ser usado entre colchetes o número da revisão do repositório que corresponde ao ''commit'' executado, exemplo: |
| | 24 | {{{ |
| | 25 | Implementado em [6] |
| | 26 | ... |
| | 27 | Corrigido em [12] |
| | 28 | }}} |
| | 29 | |
| | 30 | Com isto o Trac cria um link do que em está entre colchetes com a revisão svn dos códigos, e fica fácil então encontrar quais arquivos foram modificados para resolver o ticket. |
| | 31 | |
| | 32 | Uma consideração importante, é responsabilidade exclusiva do desenvolvedor executar estes procedimentos da forma como foram descritos, utilizando as palavras e frases reservadas, fazendo referência no svn ao ticket e no trac a revisão no svn. Caso contrário o processo de solução dos tickets se perderá, tendo o gerente do projeto ou mesmo o desenvolvedor localizar as mudanças via ''timeline'', o que não é lá uma tarefa muito agradável. |
| | 33 | |
| | 34 | == Reabertura de Tickets == |
| | 35 | |
| | 36 | A reabertura de um determinado ticket é permitida somente se tal implementação/correção ainda não foi publicada em alguma versão (Tag ou Branch). Caso o ticket fechado estiver atrelado a um marco (Milestone) que também já foi fechado, isso significa que a versão já foi publicada, e portanto, sua alteração terá ter um novo ticket para ser comitada no SVN. |
| 42 | | == Fechamento de Tickets == |
| 43 | | |
| 44 | | O fechamento deve ser feito via de regra somente após o ''commit'' no svn, pois será necessário o número da revisão do repositório para que a amarração entre o trac e o svn seja feita corretamente. Sendo assim devem ser utilizadas as frases reservadas "Implementado em" ou "Corrigido em". Implementado em indica o fechamento do ticket. Corrigido em indica a correção de um ticket que foi fechado e depois reaberto decorrente de algum problema no seu fechamento. Seguido da frase reservada deve ser usado entre colchetes o número da revisão do repositório que corresponde ao ''commit'' executado, exemplo: |
| 45 | | {{{ |
| 46 | | Implementado em [6] |
| 47 | | ... |
| 48 | | Corrigido em [12] |
| 49 | | }}} |
| 50 | | |
| 51 | | Com isto o Trac cria um link do que em está entre colchetes com a revisão svn dos códigos, e fica fácil então encontrar quais arquivos foram modificados para resolver o ticket. |
| 52 | | |
| 53 | | Uma consideração importante, é responsabilidade exclusiva do desenvolvedor executar estes procedimentos da forma como foram descritos, utilizando as palavras e frases reservadas, fazendo referência no svn ao ticket e no trac a revisão no svn. Caso contrário o processo de solução dos tickets se perderá, tendo o gerente do projeto ou mesmo o desenvolvedor localizar as mudanças via ''timeline'', o que não é lá uma tarefa muito agradável. |
| 54 | | |
| 55 | | == Reabertura de Tickets == |
| 56 | | |
| 57 | | A reabertura de um determinado ticket é permitida somente se tal implementação/correção ainda não foi publicada em alguma versão (Tag ou Branch). Caso o ticket fechado estiver atrelado a um marco (Milestone) que também já foi fechado, isso significa que a versão já foi publicada, e portanto, sua alteração terá ter um novo ticket para ser comitada no SVN. |
| 58 | | |
