https://docs.moodle.org/archive/pt/api.php?action=feedcontributions&feedformat=atom&user=Rubenback26MoodleDocs - Contribuições do utilizador [pt]2026-05-18T11:10:11ZContribuições do utilizadorMediaWiki 1.43.5https://docs.moodle.org/archive/pt/index.php?title=Guia_para_interface&diff=2536Guia para interface2008-05-26T17:57:25Z<p>Rubenback26: </p>
<hr />
<div>Este Manual de estilo para interface não é (e nem será a curto prazo) definitivo, consiste apenas num conjunto de ideias em desenvolvimento constante.<br />
<br />
<br />
== Simplicidade ==<br />
<br />
Utilize o mínimo de interface necessário para concluir uma tarefa.<br />
<br />
<br />
== Páginas Standard ==<br />
<br />
<br />
'''Módulos de actividades'''<br />
<br />
'''index.php''' – Mostra todas as opções de um módulo em curso.<br />
'''view.php''' – Mostra uma opção em particular. <br />
'''config.html''' – Configura uma opção do módulo. <br />
<br />
<br />
'''Blocos'''<br />
<br />
'''config.html''' – configura uma opção de um bloco. <br />
<br />
<br />
== Um script por função ou página principal ==<br />
<br />
... <br />
<br />
<br />
== Layout de página ==<br />
<br />
#Mostre cabeçalhos com print_heading, use os CSS hooks para IDs e Classes. <br />
#Mostre as caixas à volta do texto utilizando print_simple_box, use os CSS hooks para IDs e Classes.<br />
<br />
<br />
== Ferramentas de navegação Stardard ==<br />
<br />
#Todas as páginas devem chamar a função print_header(), e fornecer um caminho de navegação standard para ser mostrado. Onde for possível, deverá ver-se como: COURSE>> INDEX>> INSTANCE>> SUBPAGES...<br />
#As páginas incluídas em módulos de actividade devem chamar a função navmenu() para gerar o menu de navegação apropriado. <br />
<br />
<br />
<br />
== URLs ==<br />
<br />
#Os URLs devem ser tão curtos quanto possível. <br />
#Não deverão ser usados undersocres (‘_’) nos nomes dos parametros nem nos nomes dos ficheiros. <br />
#Nunca se deve usar 2 palavras quando uma só é suficiente.<br />
<br />
<br />
<br />
== Botões vs Links ==<br />
<br />
Isto é algo dificil de definir.<br />
O Google web accelarator dá algumas sugestões:<br />
#As acções que podem modificar o estado do Moodle (ficheiros de dados, base de dados, informação da sessão) devem ser realizadas por meios de botões.<br />
#Como mínimo, as acções que são implementadas usando links devem encaminhar para páginas de confirmação que utilize botões.<br />
<br />
<br />
== Nomes CSS ==<br />
<br />
Ver [[theme_standards]]. <br />
<br />
<br />
== Links de ajuda ==<br />
<br />
Os botões de ajuda devem estar posicionados à direita do objecto (excepto quando o objecto esteja alinhado à direita, devendo neste caso estar posicionados à esquerda).<br />
<br />
<br />
== Artigo de interesse ==<br />
<br />
O link que se segue apresenta um artigo denominado "Interaction Design Meets Online Real Estate" de 01 de Março de 2005 nas “últimas noticias de Robin Good”.<br />
<br />
http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br />
<br />
Este artigo contem uma visão dos espaços virtuais focados nas acções humanas. Isto tem algum paralelismo com as abordagens comunicativas como o Moodle. O interface serve como um gestor de todas ferramentas de comunicação.<br />
The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools. <br />
<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Interface guidelines]]<br />
[[es:Manual de estilo de la interfaz]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Guia_para_interface&diff=2535Guia para interface2008-05-26T17:56:16Z<p>Rubenback26: </p>
<hr />
<div>Este Manual de estilo para interface não é (e nem será a curto prazo) definitivo, consiste apenas num conjunto de ideias em desenvolvimento constante.<br />
<br />
<br />
== Simplicidade ==<br />
<br />
Utilize o mínimo de interface necessário para concluir uma tarefa.<br />
<br />
<br />
== Páginas Standard ==<br />
<br />
<br />
'''Módulos de actividades'''<br />
<br />
'''index.php''' – Mostra todas as opções de um módulo em curso.<br />
'''view.php''' – Mostra uma opção em particular. <br />
'''config.html''' – Configura uma opção do módulo. <br />
<br />
<br />
'''Blocos'''<br />
<br />
'''config.html''' – configura uma opção de um bloco. <br />
<br />
<br />
== Um script por função ou página principal ==<br />
<br />
... <br />
<br />
<br />
== Layout de página ==<br />
<br />
#Mostre cabeçalhos com print_heading, use os CSS hooks para IDs e Classes <br />
#Mostre as caixas à volta do texto utilizando print_simple_box, use os CSS hooks para IDs e Classes.<br />
<br />
<br />
== Ferramentas de navegação Stardard ==<br />
<br />
#Todas as páginas devem chamar a função print_header(), e fornecer um caminho de navegação standard para ser mostrado. Onde for possível, deverá ver-se como: COURSE>> INDEX>> INSTANCE>> SUBPAGES...<br />
#As páginas incluídas em módulos de actividade devem chamar a função navmenu() para gerar o menu de navegação apropriado. <br />
<br />
<br />
<br />
== URLs ==<br />
<br />
#Os URLs devem ser tão curtos quanto possível. <br />
#Não deverão ser usados undersocres (‘_’) nos nomes dos parametros nem nos nomes dos ficheiros. <br />
#Nunca se deve usar 2 palavras quando uma só é suficiente.<br />
<br />
<br />
<br />
== Botões vs Links ==<br />
<br />
Isto é algo dificil de definir.<br />
O Google web accelarator dá algumas sugestões:<br />
#As acções que podem modificar o estado do Moodle (ficheiros de dados, base de dados, informação da sessão) devem ser realizadas por meios de botões.<br />
#Como mínimo, as acções que são implementadas usando links devem encaminhar para páginas de confirmação que utilize botões.<br />
<br />
<br />
== Nomes CSS ==<br />
<br />
Ver [[theme_standards]]. <br />
<br />
<br />
== Links de ajuda ==<br />
<br />
Os botões de ajuda devem estar posicionados à direita do objecto (excepto quando o objecto esteja alinhado à direita, devendo neste caso estar posicionados à esquerda).<br />
<br />
<br />
== Artigo de interesse ==<br />
<br />
O link que se segue apresenta um artigo denominado "Interaction Design Meets Online Real Estate" de 01 de Março de 2005 nas “últimas noticias de Robin Good”.<br />
<br />
http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br />
<br />
Este artigo contem uma visão dos espaços virtuais focados nas acções humanas. Isto tem algum paralelismo com as abordagens comunicativas como o Moodle. O interface serve como um gestor de todas ferramentas de comunicação.<br />
The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools. <br />
<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Interface guidelines]]<br />
[[es:Manual de estilo de la interfaz]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Guia_para_interface&diff=2534Guia para interface2008-05-26T17:53:52Z<p>Rubenback26: </p>
<hr />
<div>Este Manual de estilo para interface não é (e nem será a curto prazo) definitivo, consiste apenas num conjunto de ideias em desenvolvimento constante.<br />
<br />
<br />
== Simplicidade ==<br />
<br />
Utilize o mínimo de interface necessário para concluir uma tarefa.<br />
<br />
<br />
== Páginas Standard ==<br />
<br />
<br />
'''Módulos de actividades'''<br />
<br />
'''index.php''' – Mostra todas as opções de um módulo em curso.<br />
'''view.php''' – Mostra uma opção em particular. <br />
'''config.html''' – Configura uma opção do módulo. <br />
<br />
<br />
'''Blocos'''<br />
<br />
'''config.html''' – configura uma opção de um bloco. <br />
<br />
<br />
== Um script por função ou página principal ==<br />
<br />
... <br />
<br />
<br />
== Layout de página ==<br />
<br />
#Mostre cabeçalhos com print_heading, use os CSS hooks para IDs e Classes <br />
#Mostre as caixas à volta do texto utilizando print_simple_box, use os CSS hooks para IDs e Classes.<br />
<br />
<br />
== Ferramentas de navegação Stardard ==<br />
<br />
#Todas as páginas devem chamar a função print_header(), e fornecer um caminho de navegação standard para ser mostrado. Onde for possível, deverá ver-se como: COURSE>> INDEX>> INSTANCE>> SUBPAGES...<br />
#As páginas incluídas em módulos de actividade devem chamar a função navmenu() para gerar o menu de navegação apropriado. <br />
<br />
<br />
<br />
== URLs ==<br />
<br />
#Os URLs devem ser tão curtos quanto possível. <br />
#Não deverão ser usados undersocres (‘_’) nos nomes dos parametros nem nos nomes dos ficheiros. <br />
#Nunca se deve usar 2 palavras quando uma só é suficiente.<br />
<br />
<br />
<br />
== Botões vs Links ==<br />
<br />
Isto é algo dificil de definir.<br />
O Google web accelarator dá algumas sugestões:<br />
#As acções que podem modificar o estado do Moodle (ficheiros de dados, base de dados, informação da sessão) devem ser realizadas por meios de botões.<br />
#Como mínimo, as acções que são implementadas usando links devem encaminhar para páginas de confirmação que utilize botões.<br />
<br />
<br />
== Nomes CSS ==<br />
<br />
Ver [theme standards]. <br />
<br />
<br />
== Links de ajuda ==<br />
<br />
Os botões de ajuda devem estar posicionados à direita do objecto (excepto quando o objecto esteja alinhado à direita, devendo neste caso estar posicionados à esquerda).<br />
<br />
<br />
== Artigo de interesse ==<br />
<br />
O link que se segue apresenta um artigo denominado "Interaction Design Meets Online Real Estate" de 01 de Março de 2005 nas “últimas noticias de Robin Good”.<br />
<br />
http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br />
<br />
Este artigo contem uma visão dos espaços virtuais focados nas acções humanas. Isto tem algum paralelismo com as abordagens comunicativas como o Moodle. O interface serve como um gestor de todas ferramentas de comunicação.<br />
The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools. <br />
<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Interface guidelines]]<br />
[[es:Manual de estilo de la interfaz]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Guia_para_interface&diff=2533Guia para interface2008-05-26T17:28:42Z<p>Rubenback26: </p>
<hr />
<div>Este Manual de estilo para interface não é (e nem será a curto prazo) definitivo, consiste apenas num conjunto de ideias em desenvolvimento constante.<br />
<br />
<br />
== Simplicidade ==<br />
<br />
Utilize o mínimo de interface necessário para concluir uma tarefa<br />
<br />
<br />
== Páginas Standard ==<br />
<br />
'''Módulos de actividades'''<br />
<br />
'''index.php''' – Mostra todas as opções de um módulo em curso<br />
'''view.php''' – Mostra uma opção em particular <br />
'''config.html''' – Configura uma opção do módulo <br />
<br />
<br />
'''Blocos'''<br />
<br />
'''config.html''' – configura uma opção de um bloco. <br />
<br />
<br />
== Um script por função ou página principal ==<br />
<br />
... <br />
<br />
<br />
== Layout de página ==<br />
<br />
#Mostre cabeçalhos com print_heading, use os CSS hooks para IDs e Classes <br />
#Mostre as caixas à volta do texto utilizando print_simple_box, use os CSS hooks para IDs e Classes.<br />
<br />
<br />
== Ferramentas de navegação Stardard ==<br />
<br />
#Todas as páginas devem chamar a função print_header(), e fornecer um caminho de navegação standard para ser mostrado. Onde for possível, deverá ver-se como: COURSE>> INDEX>> INSTANCE>> SUBPAGES...<br />
#As páginas incluídas em módulos de actividade devem chamar a função navmenu() para gerar o menu de navegação apropriado. <br />
<br />
<br />
<br />
== URLs ==<br />
<br />
#Os URLs devem ser tão curtos quanto possível. <br />
#Não deverão ser usados undersocres (‘_’) nos nomes dos parametros nem nos nomes dos ficheiros. <br />
#Nunca se deve usar 2 palavras quando uma só é suficiente.<br />
<br />
<br />
<br />
== Botões vs Links ==<br />
<br />
Isto é algo dificil de definir.<br />
O Google web accelarator dá algumas sugestões:<br />
#As acções que podem modificar o estado do Moodle (ficheiros de dados, base de dados, informação da sessão) devem ser realizadas por meios de botões.<br />
#Como mínimo, as acções que são implementadas usando links devem encaminhar para páginas de confirmação que utilize botões.<br />
<br />
<br />
== Nomes CSS ==<br />
<br />
Ver theme standards <br />
<br />
<br />
== Links de ajuda ==<br />
<br />
Os botões de ajuda devem estar posicionados à direita do objecto (excepto quando o objecto esteja alinhado à direita, devendo neste caso estar posicionados à esquerda).<br />
<br />
<br />
== Artigo de interesse ==<br />
<br />
O link que se segue apresenta um artigo denominado "Interaction Design Meets Online Real Estate" de 01 de Março de 2005 nas “últimas noticias de Robin Good”.<br />
<br />
http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br />
<br />
Este artigo contem uma visão dos espaços virtuais focados nas acções humanas. Isto tem algum paralelismo com as abordagens comunicativas como o Moodle. O interface serve como um gestor de todas ferramentas de comunicação.<br />
The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools. <br />
<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Interface guidelines]]<br />
[[es:Manual de estilo de la interfaz]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Tracker&diff=2532Tracker2008-05-22T11:37:54Z<p>Rubenback26: </p>
<hr />
<div>== Tracker – Sistema de gestão de bugs do Moodle ==<br />
<br />
<br />
A detecção e reparação de bugs constituem um processo contínuo de controlo de qualidade. No caso do Moodle, esta detecção e reparação de bugs, por ser uma plataforma open-source, está aberta a todos quantos queiram participar, constituindo este facto uma vantagem em relação às plataformas proprietárias. O sistema que permite fazer esta detecção e posterior correcção de erros associados à plataforma Moodle chama-se Tracker.<br />
O ponto interessante do open-source está no facto em que todos os utilizadores interessados podem ajudar de várias formas, quer no código ou na detecção de erros, com o objectivo de trabalhar num produto que seja do agrado da comunidade.<br />
<br />
<br />
== Login no Tracker ==<br />
<br />
Caso seja um novo utilizador do Tracker, o processo de registo poderá ser realizado aqui. Recomenda-se aqui que o username usado seja o mesmo do site moode.org. <br />
Caso a conta de acesso ao Tracker não funcione, a mesma pode ser recuperada aqui: http://tracker.moodle.org<br />
<br />
'''Resumo: Como reportar um erro, um melhoramento, ou um pedido de funcionalidade'''<br />
<br />
#Fazer o login na homepage do Moodle Tracker.<br />
#Seleccionar “Create New Issue” no menu baixo do logótipo do Moodle Tracker.<br />
#No passo 1, no menu desdobrável seleccionar o “Issue type”: Erro (bug), Nova Funcionalidade (New Feature), Tarefa (Task) ou Melhoramento (Improvement).<br />
#No passo 2, será visível várias áreas desdobráveis em branco.<br />
<br />
<br />
*Resumo (Summary): Breve descrição do problema. O objectivo aqui é tentar fazer com que a descrição seja o mais precisa possível. A simples expressão do “Não funciona” não se revela de grande importância. È importante também pensar as palavras-chave que identificam o problema, para que o problema seja rapidamente encontrado pelos utilizadores pesquisarem pelo mesmo erro.<br />
<br />
*Componentes (Components): usar a teclas Ctrl e com um click do rato seleccionar uma ou mais áreas do Moodle. Por exemplo, pode ser encontrado um erro numa funcionalidade que tenha impacto em vários módulos.<br />
<br />
*Seleccionar a versão do Moodle, e caso não esteja listada por informação relativa á versão na descrição.<br />
<br />
*O Ambiente (Enviroment) é para a informações relativas ao sistema operativo e outras informações. Ver guias gerais mais abaixo.<br />
*A Descrição (Descritpion) informa-nos acerca do assunto tratado. Informações sobre este tópico, mais abaixo.<br />
<br />
*Base de Dados (Database), se não estiver na lista, por a informação relativa no campo Ambiente(Enviroment)<br />
<br />
<br />
'''Guia geral para a submissão de relatórios'''<br />
<br />
Um bom relatório deve incluir:<br />
*Resumo do problema em uma ou 2 frases<br />
*Descrição concreta e concisa do problema ou melhoramento em causa<br />
*Deve ser também feita uma descrição passo-a-passo da sequência de passos a fazer com o objectivo de reproduzir o erro. Se possível, indicar o endereço para o que o programador consiga ver o erro apenas com um click.<br />
*Resultados actuais: indicar o que é que a aplicação faz após os passos serem executados<br />
*Resultados esperados: explicitar os resultados que são esperados, caso o erro não estivesse presente. É importante que a explicação seja bastante pormenorizada pois isso ajudará na resolução do erro, bem como no interface que poderá ser ajustado de forma a ser mais amigável.<br />
<br />
Se possível, incluir informação adicional que possa ser útil ao programador:<br />
*Versão do Moodle (se a versão não se encontrar no menu desdobrável no topo do formulário, adicionar essa informação na descrição)<br />
*Se existir uma mensagem de erro ou outra informação, quer nos logs do PHP ou do servidor web, inclua uma cópia dessa informação no relatório. Se for possível, ligar o modo “debug” na página configuração do Administrador com o objectivo de obter a melhor mensagem de erro possível.<br />
<br />
*Os ecrãs capturados podem também ser uma grande ajuda, mas devem ser acompanhados de uma descrição.<br />
*Fornecer as informações relativas à configuração do sistema operativo, base de dados, etc. Se o espaço disponível na secção Ambiente (Enviroment), pode ser feita a continuação na secção da descrição. Algumas das informações que neste caso podem ser relevantes, são:<br />
<br />
**Sistema operativo do servidor e número de versão.<br />
**Tipo de servidor e número de versão.<br />
**Versão de PHP usada (e se é usado algum optimizador).<br />
**Tipo de base de dados e número de versão.<br />
**Tipo de sistema operativo do cliente e número de versão.<br />
**Tipo e número de versão do browser utilizado.<br />
<br />
*Não é necessário fornecer sempre todos os dados. Por exemplo, se for um problema de layout, será só necessário fornecer informação sobre o sistema operativo e browsers utilizados pelos clientes. Ficam aqui alguns exemplos:<br />
**Detecção de um erro na última versão do HEAD do Moodle, a correr em PHP5.1.2/Apache 2.2.3 em Linux. A base de dados utilizada é Postgres 8.1.<br />
**Existe um problema de renderização, utilizando o Internet Explorer 6.0 em Windows XP.<br />
<br />
Em resumo, deve fazer-se uma reunião de facto suficientemente boa para que outros utilizadores possam duplicar o problema.<br />
<br />
Aqui estão alguns exemplos de boas práticas na submissão de relatórios de erro: MDL-6030, MDL-5688, MDL-12505.<br />
Muitas vezes a parte difícil neste processo, não consiste na reparação do erro, mas sim na reprodução do mesmo por parte do programador. O programador tem assim de poder conseguir reproduzir o erro submetido, caso contrário nunca o poderá resolver.<br />
<br />
Bons relatórios são os que contêm informação o mais detalhada e especifica possível. <br />
Por exemplo, um relatório de erro que contenha apenas “ O feed RSS não suporta UTF-8” não ajuda em nada. O programador sabe que o UTF-8 e os RSS feeds são compatíveis. Além do mais o programador não faz ideia do que o utilizador vê no seu computador e porque submeteu o erro. Neste caso terá de ser dispendido mais tempo e esforço na determinação de qual será o problema.<br />
<br />
<br />
== O processo do Tracker ==<br />
<br />
<br />
'''Acompanhamento de novas matérias e melhorias'''<br />
<br />
Qualquer um com uma conta no Tracker pode acompanhar matérias que são submetidas. Acima estão descritas boas práticas sobre como escrever relatórios de erro de boa qualidade. É importante procurar no Tracker para determinar se o seu problema ou sugestão para a melhoria foram já objecto de relatório. Caso exista a intenção de adicionar mais informação (use a função do “comment”), voto para a edição, ou acompanhar para ver mais tarde (watch it).<br />
Receberá depois um email cada vez que for subscrito um novo erro novo ou forem feitas actualizações aos erros que foram relatados. Será também enviada uma notificação quando são feitas actualizações aos erros que foram marcados para serem acompanhados.<br />
<br />
Podem também ser monitorizados ou acompanhados, erros submetidos por outros utilizadores. Para fazer isto, abra o erro em questão, depois seleccione “Watch it” que se encontra na parte esquerda do painel de navegação. Para que outras pessoas sejam adicionadas para acompanhar problemas submetidos por nós, seleccionar a opção “Watching” que se encontra na parte esquerda do painel de navegação. Essas pessoas serão depois notificadas por correio electrónico cada vez que houver uma actualização ao problema.<br />
<br />
O Tracker fornece uma facilidade fazer o link entre matérias submetidas. Qualquer usuário registado no Tracker pode ligar matérias. Os tipos de ligação múltipla estão definidos no sistema; será solicitada a escolha de um tipo ao ser feito o link de erros. Veja [nome da secção da inserção] para lista detalhada de tipos da ligação.<br />
<br />
Vote em erros que você quer ver abordados no Moodle. Todos os utilizadores podem votar. Para votar para um erro específico, seleccione o erro, seleccionando depois “Vote for it” do painel de navegação esquerdo. Os programadores podem considerar o número dos votos que um erro tem para fazer a escolha entre dois ou mais erros.<br />
<br />
O painel (Dashboard) do Tracker é flexível e pode ser modificado conforme as áreas de interesse de cada utilizador. Para mais instruções acerca da configuração do Painel do Tracker clicar aqui.<br />
O Issue Navigator do Tracker é a ferramenta que permite encontrar e filtrar erros. Para mais instruções sobre o Issue Navigator clicar aqui.<br />
<br />
A função de pesquisa rápida (Quick Search) do Tracker está explicada aqui.<br />
<br />
<br />
'''Resolvendo assuntos no Tracker'''<br />
<br />
Só os programadores e responsáveis pelos testes ao Moodle têm permissão para mudar o estado dos erros no Tracker para “resolvido” ou “fechado” ("resolved" or "closed").<br />
<br />
Este é o processo geral que o programador irá seguir, quando mudar o estado de um assunto referido no Tracker:<br />
#Os assuntos são automaticamente atribuídos no momento da sua criação tendo como base o componente a que são relativos; caso os programadores ou os responsáveis do componente entendam, o assunto pode ser novamente atribuído a outro módulo<br />
#Os programadores reparam, modificam ou adicionam código e fazzem a verificação do CVS. O número que identifica o assunto no Tracker faz automaticamente a ligação entre a mudanças no CVS ao Tracker.<br />
#Os patchs estão anexos aos assuntos no Tracker para que possam ser analisados e depois possivelmente adicionados no CVS. <br />
#Devem ser acrescentados comentários no Tracker com a descrição da reparação feita. O estado do erro é depois alterado para Resolvido (Resolved).<br />
#O programador deve indicar em que versão do Moodle a alteração irá ser incluída usando o Fix Version/s. Deve depois ser indicado qual o ramo ou ramos nos quais a alteração foi verificada<br />
#A única excepção que pode existir na alteração de estado de um erro para Resolvido (Resolved) dá-se no caso de o programador entender que não existe valor em testar o assunto resolvido. Neste caso a alteração de estado será para Fechado (Closed).<br />
<br />
<br />
'''Testes á plataforma'''<br />
<br />
Todos os utilizadores são incentivados a serem participantes activos no que diz respeito a testar o Moodle. Qualquer pessoa que tenha um registo no Tracker pode registar, ver, comentar, votar, e acompanhar erros. Caso existam alguns erros, problemas, ideias para aperfeiçoamentos, o se existir o desejo de que alguma funcionalidade seja adicionada ao Moodle, o utilizador deve reportar isso no Tracker.<br />
<br />
Foi formalizado um grupo de pessoas responsáveis por fazer testes no Tracker que são responsáveis por verificar o rigor das alterações feitas pelos programadores. Este grupo de pessoas tem responsabilidades e autoridade no Tracker que vão além do utilizador comum. Além disto são utilizadores com grande conhecimento de toda a estrutura do Moodle, sendo também membros muito activos na comunidade Moodle. É claro que estes devem ter um nível suficiente em termos de atributos e conhecimentos necessários para os testes que realizam – a experiência é muito importante – mas também não pode ser esquecido que existem sempre utilizadores na comunidade dispostos a ajudar em qualquer eventualidade. Se quiser fazer parte da Equipa de Testes do Moodle, manifeste a sua intenção reportando-a no Tracker. Reporte a sua intenção em Moodle.org Sites Tracker project.<br />
<br />
<br />
'''Teste de erros no Tracker'''<br />
<br />
Este é o processo que a equipa de testes do Moodle deve seguir para alterar o estado dos erros de resolvidos (resolved) para fechados (closed).<br />
<br />
*Os membros desta equipa testam os erros que se encontram no estado Resolvido (Resolved). Foram criados filtros global baseados em futuros lançamentos (ex. 1.9 Resolvido) para que a identificação seja feita de uma maneira mais facilitada.<br />
*Usar o campo QA Assignee para fazer a identificação como inspector (membro responsável pelos testes) do erro.<br />
*Uma boa ideia será subscrever todos os tópicos relativos aos erros que são testados (ex. todos os erros em que nós fomos responsáveis pela fase de testes).<br />
*Caso o erro passar a fase de testes, alterar o estado do erro usando o botão “Fechar Assunto” (“Close Issue”). Devem ser adicionados comentários com a descrição do método usado para fazer os testes, todas as incorrecções encontradas, etc.<br />
*Caso o erro não passe a fase de testes ou se houver o sentimento de que o erro não foi completamente reparado, deve fazer-se a alteração do seu estado através do botão “Reabrir Assunto” (“Reopen Issue”) de forma a este ficar novamente com a indicação que não está completamente resolvido. Certificar-se de que o problema é entregue ao programador correcto. Trabalhar com o programador no sentido de ser encontrada uma resolução que seja acertada para ambas as partes.<br />
<br />
*Uma versão será dada como pronta quando todos os erros a ela relativos forem dados como estando fechados.<br />
*Todos os erros resolvidos devem ser testados. Erros que no final tenham a indicação de reparados (fixed) representam erros sujo o seu código foi actualizado, e provavelmente representaram um maior desafio do que os erros que tenham no final a indicação de sendo duplicados, que não constituem um erro, ou que foi conseguido reproduzir esse erro. É aconselhável a certificação de que os erros foram finalizados com a indicação correcta. Infelizmente não é fácil alterar o código quando ele é posto no Tracker ( a única solução será reabrir e depois fechar o tópico).<br />
<br />
*Os processos de teste devem ser discutidos sem receios com os programadores afectos ao erro. Muitas vezes um comentário chama logo a atenção do programador enquanto são notificados de todas as mudanças.<br />
<br />
<br />
'''Descrição detalhada de todos os grupos e campos do Tracker'''<br />
<br />
Em cada campo no Tracker é sempre apresentada uma pequena explicação.<br />
<br />
'''Projecto''' (Project) – Campo obrigatório - o Tracker é constituído por vários projectos. No presente existem 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. Escolha ‘moodle’ para erros/assuntos relacionados com o software moodle; escolha 'moodle.org sites' para erros/assuntos relacionados com tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, ou moodle.org; escolha 'Non-core contributed modules' para erros/assuntos relacionados com módulos.<br />
<br />
'''Tipo de assunto''' (Issue Type) - Campo obrigatório – os erros são classificados segundo as seguintes categorias:<br />
*Erro (bug)- um problema que afecta o funcionamento correcto do Moodle.<br />
*Melhoramento (Improvement) - uma melhoria a uma funcionalidade já existente no Moodle<br />
*Nova funcionalidade (New Feature) – uma nova funcionalidade que tem ainda de ser desenvolvida<br />
*Tarefa (Task) – uma tarefa que necessita de ser completada. Usualmente refere-se a trabalho que tem de ser executado fora do âmbito do produto.<br />
*Sub-tarefa (Sub-task) – assuntos que por vezes são divididos em assuntos mais pequenos <br />
<br />
'''Sumário''' (Summary) - Campo obrigatório – uma descrição breve e concisa do problema.<br />
<br />
Nível de segurança (Security Level) – Campo opcional. Indica se o erro ou modificação tem implicações de segurança para o Moodle. Erros que tenham seriam implicações a nível de segurança, são reservados para a equipa de segurança do Moodle.<br />
<br />
'''Prioridade''' (Priority) – os erros têm os seguintes níveis de prioridade:<br />
*Blocker – bloqueia o desenvolvimento e/ou trabalho de teste, a produção não pode continuar. <br />
*Critical - Crashes, perdas de informação, fugas sérias a nível de memória. <br />
*Major – perda importante de funcionalidade. <br />
*Minor – perda de uma funcionalidade acessória, ou outro problema de fácil resolução<br />
*Trivial – problema de nível cosmético como por exemplo erros ortográficos ou texto desalinhado <br />
<br />
'''Componentes''' (Components) – Campo obrigatório. Seleccionar a área do Moodle afectada pelo erro. Em caso de incerteza, seleccionar “Unknown”.<br />
<br />
'''Versão Afectada''' (Affects Version) – Campo obrigatório. Esta é a versão do Moodle na qual o erro foi encontrado. Esta informação é inserida pela pessoa que reporta o erro, e normalmente apenas uma versão é apontada. Inserir a versão actual no momento em que se reporta o melhoramento, tarefa ou nova funcionalidade ajudará avaliar o estado do produto quando o pedido foi feito.<br />
<br />
'''Afecto a''' (Assigned To) – Esta será a pessoa a que irá ser responsável pela resolução do problema. Este campo irá ser preenchido por programadores ou equipas responsáveis por módulos.<br />
<br />
'''Reportador''' (Reporter) – Pessoa que reporta o erro. Este campo é automaticamente preenchido pelo Tracker. <br />
Ambiente (Environment) – Especifica qual o sistema operative, plataforma de software e/ou especificações de hardware, se aplicáveis ao erro em questão.<br />
<br />
'''Descrição''' (Description) – Uma descrição complete e concise do problema ou melhoramento. <br />
<br />
'''Base de dados''' (Database) – Campo opcional. Se for aplicável ao erro, identifica o tipo de base de dados utilizado. <br />
URL – Campo opcional. Se possivel, fornecer o endereço URL que demonstre um exemplo do erro. <br />
<br />
'''Responsável pelos testes''' (QA Assignee) – Usado para designer o responsável que irá fazer os testes. <br />
<br />
'''Versões reparadas''' (Fixed Version/s) – Versão do Moodle onde o erro esteve ou irá ser reparado. Basicamente deverá ser pensado em que notas de lançamento irão aparecer as alterações. Este campo é normalmente completado pelo programador quando o erro é dado como resolvido, ou então pelas equipas de desenvolvimento que afectaram os erros a determinada versão. Normalmente apenas uma versão é referida neste campo. Temos assim a indicação de qual a primeira versão onde a alteração irá ser visível. <br />
<br />
Exemplo: depois da versão 1.9 ser lançada, ser for reparado um erro na versão MOODLE_19_STABLE, ela irá ser marcada como reparada na versão 1.9.1. Se a reparação for a uma versão anterior, como por exemplo MOODLE_18_STABLE, deverá também ser adicionada na versão seguinte 1.8.x .<br />
<br />
Se for resolvido um erro como tudo menos “Reparado” (Não possível de reproduzir, Não Reparado, etc) deixar este campo em branco.<br />
<br />
Se for resolvido um erro anteriormente duplicado, deve ser criado um link para o duplicado do erro.<br />
<br />
Este campo é usado automaticamente para construir as notas de lançamento da versão (ver http://tracker.moodle.org/browse/MDL).<br />
<br />
'''Anexos''' (Attachment) - Opcional. Anexar um ficheiro que possa ajudar os programadores e responsáveis por testes a perceber melhor qual o erro. O tamanho máximo do anexo é de 512 Kb. <br />
<br />
'''Comentário''' (Comment) – O campo destinado aos comentários contém um registo detalhado de todas as alterações feitas a este erro. <br />
<br />
'''Resolution''' – Este campo apenas está disponível no momento de resolver ou fechar o erro. Deve então ser especificado no cógigo o modo como foi feita a resolução do erro. <br />
<br />
'''Reparado''' (Fixed) – O erro foi reparado; o código irá ser alterado no sistema CVS. Este código de resolução deve ser usado apenas quando forem feitas alterações ao código do Moodle.<br />
<br />
'''Impossível de reparar''' (Won't Fix) – O problema descrito diz respeito a um assunto que nunca irá ser reparado.<br />
<br />
'''Não é erro''' (Not a bug) – Não se trata de um erro; foi erradamente reportado. Use este código se o erro foi anteriormente reportado e reparado numa versão anterior do Moodle. <br />
<br />
'''Duplicado''' (Duplicate) – O problema é duplicado de outro problema já existente. <br />
<br />
'''Incompleto''' (Incomplete) – É necessária mais informação para a compreensão do problema. <br />
<br />
'''Impossível de reproduzir o erro''' (Can't Reproduce) – Todas as tentativas de reproduzir o erro falharam, ou não existia suficiente informação para que fosse possível a sua reprodução. A leitura do código não fornece pistas sobre a razão porque existe determinado comportamento. Se entretanto mais informações relevantes aparecerem, o assunto será novamente reaberto. <br />
<br />
'''Adiado''' (Deferred) – A resolução do problema será adiada para uma futura versão que será lançada. <br />
<br />
<br />
== Grupos do Tracker e Permissões ==<br />
<br />
<br />
Utilizadores normais [groupname=jira-user] - Este é o grupo por defeito. As novas contas de utilizador são colocadas neste grupo na altura da sua criação, e os utilizadores devem ser membros deste grupo para poderem submeter relatórios no Tracker. Os membros deste grupo podem pesquisar erros, criar erros novos, comentar erros, criar anexos, criar sub-tarefas, criar filtros, subscrever erros, e votar em erros. Os membros deste grupo podem também resolver erros, que é primeiramente uma maneira de fechar os erros que são já não relevantes (por exemplo duplicados, ou reportados por engano). Os utilizadores padrão podem configurar seu Tracker que o espaço de trabalho usando o botão "Configure your Issue Navigator". Esta característica permite que os utilizadores vejam as suas subscrições e listas de votos e controlem preferências, perfil, e senhas relativas ao Tracker.<br />
<br />
Programadores [groupname=jira-developer] - Os programadores podem fazer tudo o que utilizadores normais podem fazer. Além podem duplicar erros, subscrever erros, editar erros, ligar erros, e atribuir erros. Os membros deste grupo podem também usar a função Bulk Edit que permite a actualização bulk de múltiplos erros.<br />
<br />
Responsáveis por testes [groupname=moodle-testers] – Os responsáveis por executar testes, podem fazer tudo o que os programadores fazem.<br />
<br />
Grupos de segurança do Moodle [groupname=moodle-security] – Programadores acreditados e administradores que necessitam de trabalhar no sentido de desenvolver competências na área de segurança. <br />
<br />
<br />
'''Tipos de ligações'''<br />
<br />
Estão disponíveis os seguintes tipos de ligações:<br />
*Duplicados (duplicates) – duplicados são inevitáveis num projecto com a dimensão do Moodle. Ocorrem quando um utilizador reporta inconscientemente um erro relativo a um problema que já existe. Usa-se assim esta ligação para fazer a conexão entre o outro problema que estará descrito de modo mais compreensivo. Todos erros duplicados devem ser ligados.<br />
*Bloqueador (blockers) – usar esta ligação para a identificação de problemas que estão a bloquear a reparação de outros. <br />
*Clonadores (cloners) –nalguns casos um erros é propositadamente duplicado com o objectivo de reparar outro ramo de código – este sistema quase nunca é usado no projecto Moodle. <br />
*Dependência (dependency) – muitas vezes a reparação de uma falha está dependente de outra falha que deverá ser resolvida primeiro. Este tipo de ligações serve assim para definir a ordem pela qual deveram ser resolvidos erros que são dependentes entre si. <br />
*Correlações (relates) – é usado para identificar um erros que pode de alguma maneira estar relacionado com outro erro existente. <br />
<br />
'''Não receie ligar os erros entre si'''. As ligações são bidireccionais o que significa que existe um conceito que prevê os dois sentidos da ligação – isto afecta a maneira como os erros são mostrados. Esta é a razão pela qual de poderá ver “bloqueado /está bloqueado por” ou “duplicado/é duplicado de” na lista de ligações “Link Issue”. Não precisa de existir muita preocupação em colocar o tipo correcto de ligação, uma vez que todos funcionam de maneira semenhante.<br />
<br />
<br />
[[Category:Programador]]<br />
[[Category:Professor]]<br />
[[Category:Administrador]]<br />
<br />
[[en:Tracker]]<br />
[[es:Sistema de bugs]]<br />
[[fr:Traqueur de bogues]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Tracker&diff=2531Tracker2008-05-22T11:32:23Z<p>Rubenback26: </p>
<hr />
<div>== Tracker – Sistema de gestão de bugs do Moodle ==<br />
<br />
<br />
A detecção e reparação de bugs constituem um processo contínuo de controlo de qualidade. No caso do Moodle, esta detecção e reparação de bugs, por ser uma plataforma open-source, está aberta a todos quantos queiram participar, constituindo este facto uma vantagem em relação às plataformas proprietárias. O sistema que permite fazer esta detecção e posterior correcção de erros associados à plataforma Moodle chama-se Tracker.<br />
O ponto interessante do open-source está no facto em que todos os utilizadores interessados podem ajudar de várias formas, quer no código ou na detecção de erros, com o objectivo de trabalhar num produto que seja do agrado da comunidade.<br />
<br />
<br />
== Login no Tracker ==<br />
<br />
Caso seja um novo utilizador do Tracker, o processo de registo poderá ser realizado aqui. Recomenda-se aqui que o username usado seja o mesmo do site moode.org. <br />
Caso a conta de acesso ao Tracker não funcione, a mesma pode ser recuperada aqui: http://tracker.moodle.org<br />
<br />
'''Resumo: Como reportar um erro, um melhoramento, ou um pedido de funcionalidade'''<br />
<br />
#Fazer o login na homepage do Moodle Tracker.<br />
#Seleccionar “Create New Issue” no menu baixo do logótipo do Moodle Tracker.<br />
#No passo 1, no menu desdobrável seleccionar o “Issue type”: Erro (bug), Nova Funcionalidade (New Feature), Tarefa (Task) ou Melhoramento (Improvement).<br />
#No passo 2, será visível várias áreas desdobráveis em branco.<br />
<br />
<br />
*Resumo (Summary): Breve descrição do problema. O objectivo aqui é tentar fazer com que a descrição seja o mais precisa possível. A simples expressão do “Não funciona” não se revela de grande importância. È importante também pensar as palavras-chave que identificam o problema, para que o problema seja rapidamente encontrado pelos utilizadores pesquisarem pelo mesmo erro.<br />
<br />
*Componentes (Components): usar a teclas Ctrl e com um click do rato seleccionar uma ou mais áreas do Moodle. Por exemplo, pode ser encontrado um erro numa funcionalidade que tenha impacto em vários módulos.<br />
<br />
*Seleccionar a versão do Moodle, e caso não esteja listada por informação relativa á versão na descrição.<br />
<br />
*O Ambiente (Enviroment) é para a informações relativas ao sistema operativo e outras informações. Ver guias gerais mais abaixo.<br />
*A Descrição (Descritpion) informa-nos acerca do assunto tratado. Informações sobre este tópico, mais abaixo.<br />
<br />
*Base de Dados (Database), se não estiver na lista, por a informação relativa no campo Ambiente(Enviroment)<br />
<br />
<br />
'''Guia geral para a submissão de relatórios'''<br />
<br />
Um bom relatório deve incluir:<br />
*Resumo do problema em uma ou 2 frases<br />
*Descrição concreta e concisa do problema ou melhoramento em causa<br />
*Deve ser também feita uma descrição passo-a-passo da sequência de passos a fazer com o objectivo de reproduzir o erro. Se possível, indicar o endereço para o que o programador consiga ver o erro apenas com um click.<br />
*Resultados actuais: indicar o que é que a aplicação faz após os passos serem executados<br />
*Resultados esperados: explicitar os resultados que são esperados, caso o erro não estivesse presente. É importante que a explicação seja bastante pormenorizada pois isso ajudará na resolução do erro, bem como no interface que poderá ser ajustado de forma a ser mais amigável.<br />
<br />
Se possível, incluir informação adicional que possa ser útil ao programador:<br />
*Versão do Moodle (se a versão não se encontrar no menu desdobrável no topo do formulário, adicionar essa informação na descrição)<br />
*Se existir uma mensagem de erro ou outra informação, quer nos logs do PHP ou do servidor web, inclua uma cópia dessa informação no relatório. Se for possível, ligar o modo “debug” na página configuração do Administrador com o objectivo de obter a melhor mensagem de erro possível.<br />
<br />
*Os ecrãs capturados podem também ser uma grande ajuda, mas devem ser acompanhados de uma descrição.<br />
*Fornecer as informações relativas à configuração do sistema operativo, base de dados, etc. Se o espaço disponível na secção Ambiente (Enviroment), pode ser feita a continuação na secção da descrição. Algumas das informações que neste caso podem ser relevantes, são:<br />
<br />
**Sistema operativo do servidor e número de versão.<br />
**Tipo de servidor e número de versão.<br />
**Versão de PHP usada (e se é usado algum optimizador).<br />
**Tipo de base de dados e número de versão.<br />
**Tipo de sistema operativo do cliente e número de versão.<br />
**Tipo e número de versão do browser utilizado.<br />
<br />
*Não é necessário fornecer sempre todos os dados. Por exemplo, se for um problema de layout, será só necessário fornecer informação sobre o sistema operativo e browsers utilizados pelos clientes. Ficam aqui alguns exemplos:<br />
**Detecção de um erro na última versão do HEAD do Moodle, a correr em PHP5.1.2/Apache 2.2.3 em Linux. A base de dados utilizada é Postgres 8.1.<br />
**Existe um problema de renderização, utilizando o Internet Explorer 6.0 em Windows XP.<br />
<br />
Em resumo, deve fazer-se uma reunião de facto suficientemente boa para que outros utilizadores possam duplicar o problema.<br />
<br />
Aqui estão alguns exemplos de boas práticas na submissão de relatórios de erro: MDL-6030, MDL-5688, MDL-12505.<br />
Muitas vezes a parte difícil neste processo, não consiste na reparação do erro, mas sim na reprodução do mesmo por parte do programador. O programador tem assim de poder conseguir reproduzir o erro submetido, caso contrário nunca o poderá resolver.<br />
<br />
Bons relatórios são os que contêm informação o mais detalhada e especifica possível. <br />
Por exemplo, um relatório de erro que contenha apenas “ O feed RSS não suporta UTF-8” não ajuda em nada. O programador sabe que o UTF-8 e os RSS feeds são compatíveis. Além do mais o programador não faz ideia do que o utilizador vê no seu computador e porque submeteu o erro. Neste caso terá de ser dispendido mais tempo e esforço na determinação de qual será o problema.<br />
<br />
<br />
== O processo do Tracker ==<br />
<br />
<br />
'''Acompanhamento de novas matérias e melhorias'''<br />
<br />
Qualquer um com uma conta no Tracker pode acompanhar matérias que são submetidas. Acima estão descritas boas práticas sobre como escrever relatórios de erro de boa qualidade. É importante procurar no Tracker para determinar se o seu problema ou sugestão para a melhoria foram já objecto de relatório. Caso exista a intenção de adicionar mais informação (use a função do “comment”), voto para a edição, ou acompanhar para ver mais tarde (watch it).<br />
Receberá depois um email cada vez que for subscrito um novo erro novo ou forem feitas actualizações aos erros que foram relatados. Será também enviada uma notificação quando são feitas actualizações aos erros que foram marcados para serem acompanhados.<br />
<br />
Podem também ser monitorizados ou acompanhados, erros submetidos por outros utilizadores. Para fazer isto, abra o erro em questão, depois seleccione “Watch it” que se encontra na parte esquerda do painel de navegação. Para que outras pessoas sejam adicionadas para acompanhar problemas submetidos por nós, seleccionar a opção “Watching” que se encontra na parte esquerda do painel de navegação. Essas pessoas serão depois notificadas por correio electrónico cada vez que houver uma actualização ao problema.<br />
<br />
O Tracker fornece uma facilidade fazer o link entre matérias submetidas. Qualquer usuário registado no Tracker pode ligar matérias. Os tipos de ligação múltipla estão definidos no sistema; será solicitada a escolha de um tipo ao ser feito o link de erros. Veja [nome da secção da inserção] para lista detalhada de tipos da ligação.<br />
<br />
Vote em erros que você quer ver abordados no Moodle. Todos os utilizadores podem votar. Para votar para um erro específico, seleccione o erro, seleccionando depois “Vote for it” do painel de navegação esquerdo. Os programadores podem considerar o número dos votos que um erro tem para fazer a escolha entre dois ou mais erros.<br />
<br />
O painel (Dashboard) do Tracker é flexível e pode ser modificado conforme as áreas de interesse de cada utilizador. Para mais instruções acerca da configuração do Painel do Tracker clicar aqui.<br />
O Issue Navigator do Tracker é a ferramenta que permite encontrar e filtrar erros. Para mais instruções sobre o Issue Navigator clicar aqui.<br />
<br />
A função de pesquisa rápida (Quick Search) do Tracker está explicada aqui.<br />
<br />
<br />
'''Resolvendo assuntos no Tracker'''<br />
<br />
Só os programadores e responsáveis pelos testes ao Moodle têm permissão para mudar o estado dos erros no Tracker para “resolvido” ou “fechado” ("resolved" or "closed").<br />
<br />
Este é o processo geral que o programador irá seguir, quando mudar o estado de um assunto referido no Tracker:<br />
#Os assuntos são automaticamente atribuídos no momento da sua criação tendo como base o componente a que são relativos; caso os programadores ou os responsáveis do componente entendam, o assunto pode ser novamente atribuído a outro módulo<br />
#Os programadores reparam, modificam ou adicionam código e fazzem a verificação do CVS. O número que identifica o assunto no Tracker faz automaticamente a ligação entre a mudanças no CVS ao Tracker.<br />
#Os patchs estão anexos aos assuntos no Tracker para que possam ser analisados e depois possivelmente adicionados no CVS. <br />
#Devem ser acrescentados comentários no Tracker com a descrição da reparação feita. O estado do erro é depois alterado para Resolvido (Resolved).<br />
#O programador deve indicar em que versão do Moodle a alteração irá ser incluída usando o Fix Version/s. Deve depois ser indicado qual o ramo ou ramos nos quais a alteração foi verificada<br />
#A única excepção que pode existir na alteração de estado de um erro para Resolvido (Resolved) dá-se no caso de o programador entender que não existe valor em testar o assunto resolvido. Neste caso a alteração de estado será para Fechado (Closed).<br />
<br />
<br />
'''Testes á plataforma'''<br />
<br />
Todos os utilizadores são incentivados a serem participantes activos no que diz respeito a testar o Moodle. Qualquer pessoa que tenha um registo no Tracker pode registar, ver, comentar, votar, e acompanhar erros. Caso existam alguns erros, problemas, ideias para aperfeiçoamentos, o se existir o desejo de que alguma funcionalidade seja adicionada ao Moodle, o utilizador deve reportar isso no Tracker.<br />
<br />
Foi formalizado um grupo de pessoas responsáveis por fazer testes no Tracker que são responsáveis por verificar o rigor das alterações feitas pelos programadores. Este grupo de pessoas tem responsabilidades e autoridade no Tracker que vão além do utilizador comum. Além disto são utilizadores com grande conhecimento de toda a estrutura do Moodle, sendo também membros muito activos na comunidade Moodle. É claro que estes devem ter um nível suficiente em termos de atributos e conhecimentos necessários para os testes que realizam – a experiência é muito importante – mas também não pode ser esquecido que existem sempre utilizadores na comunidade dispostos a ajudar em qualquer eventualidade. Se quiser fazer parte da Equipa de Testes do Moodle, manifeste a sua intenção reportando-a no Tracker. Reporte a sua intenção em Moodle.org Sites Tracker project.<br />
<br />
<br />
'''Teste de erros no Tracker'''<br />
<br />
Este é o processo que a equipa de testes do Moodle deve seguir para alterar o estado dos erros de resolvidos (resolved) para fechados (closed).<br />
<br />
*Os membros desta equipa testam os erros que se encontram no estado Resolvido (Resolved). Foram criados filtros global baseados em futuros lançamentos (ex. 1.9 Resolvido) para que a identificação seja feita de uma maneira mais facilitada.<br />
*Usar o campo QA Assignee para fazer a identificação como inspector (membro responsável pelos testes) do erro.<br />
*Uma boa ideia será subscrever todos os tópicos relativos aos erros que são testados (ex. todos os erros em que nós fomos responsáveis pela fase de testes).<br />
*Caso o erro passar a fase de testes, alterar o estado do erro usando o botão “Fechar Assunto” (“Close Issue”). Devem ser adicionados comentários com a descrição do método usado para fazer os testes, todas as incorrecções encontradas, etc.<br />
*Caso o erro não passe a fase de testes ou se houver o sentimento de que o erro não foi completamente reparado, deve fazer-se a alteração do seu estado através do botão “Reabrir Assunto” (“Reopen Issue”) de forma a este ficar novamente com a indicação que não está completamente resolvido. Certificar-se de que o problema é entregue ao programador correcto. Trabalhar com o programador no sentido de ser encontrada uma resolução que seja acertada para ambas as partes.<br />
<br />
*Uma versão será dada como pronta quando todos os erros a ela relativos forem dados como estando fechados.<br />
*Todos os erros resolvidos devem ser testados. Erros que no final tenham a indicação de reparados (fixed) representam erros sujo o seu código foi actualizado, e provavelmente representaram um maior desafio do que os erros que tenham no final a indicação de sendo duplicados, que não constituem um erro, ou que foi conseguido reproduzir esse erro. É aconselhável a certificação de que os erros foram finalizados com a indicação correcta. Infelizmente não é fácil alterar o código quando ele é posto no Tracker ( a única solução será reabrir e depois fechar o tópico).<br />
<br />
*Os processos de teste devem ser discutidos sem receios com os programadores afectos ao erro. Muitas vezes um comentário chama logo a atenção do programador enquanto são notificados de todas as mudanças.<br />
Descrição detalhada de todos os grupos e campos do Tracker<br />
<br />
Em cada campo no Tracker é sempre apresentada uma pequena explicação.<br />
<br />
'''Projecto''' (Project) – Campo obrigatório - o Tracker é constituído por vários projectos. No presente existem 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. Escolha ‘moodle’ para erros/assuntos relacionados com o software moodle; escolha 'moodle.org sites' para erros/assuntos relacionados com tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, ou moodle.org; escolha 'Non-core contributed modules' para erros/assuntos relacionados com módulos.<br />
<br />
'''Tipo de assunto''' (Issue Type) - Campo obrigatório – os erros são classificados segundo as seguintes categorias:<br />
*Erro (bug)- um problema que afecta o funcionamento correcto do Moodle.<br />
*Melhoramento (Improvement) - uma melhoria a uma funcionalidade já existente no Moodle<br />
*Nova funcionalidade (New Feature) – uma nova funcionalidade que tem ainda de ser desenvolvida<br />
*Tarefa (Task) – uma tarefa que necessita de ser completada. Usualmente refere-se a trabalho que tem de ser executado fora do âmbito do produto.<br />
*Sub-tarefa (Sub-task) – assuntos que por vezes são divididos em assuntos mais pequenos <br />
<br />
'''Sumário''' (Summary) - Campo obrigatório – uma descrição breve e concisa do problema.<br />
<br />
Nível de segurança (Security Level) – Campo opcional. Indica se o erro ou modificação tem implicações de segurança para o Moodle. Erros que tenham seriam implicações a nível de segurança, são reservados para a equipa de segurança do Moodle.<br />
<br />
'''Prioridade''' (Priority) – os erros têm os seguintes níveis de prioridade:<br />
*Blocker – bloqueia o desenvolvimento e/ou trabalho de teste, a produção não pode continuar. <br />
*Critical - Crashes, perdas de informação, fugas sérias a nível de memória. <br />
*Major – perda importante de funcionalidade. <br />
*Minor – perda de uma funcionalidade acessória, ou outro problema de fácil resolução<br />
*Trivial – problema de nível cosmético como por exemplo erros ortográficos ou texto desalinhado <br />
<br />
'''Componentes''' (Components) – Campo obrigatório. Seleccionar a área do Moodle afectada pelo erro. Em caso de incerteza, seleccionar “Unknown”.<br />
<br />
'''Versão Afectada''' (Affects Version) – Campo obrigatório. Esta é a versão do Moodle na qual o erro foi encontrado. Esta informação é inserida pela pessoa que reporta o erro, e normalmente apenas uma versão é apontada. Inserir a versão actual no momento em que se reporta o melhoramento, tarefa ou nova funcionalidade ajudará avaliar o estado do produto quando o pedido foi feito.<br />
<br />
'''Afecto a''' (Assigned To) – Esta será a pessoa a que irá ser responsável pela resolução do problema. Este campo irá ser preenchido por programadores ou equipas responsáveis por módulos.<br />
<br />
'''Reportador''' (Reporter) – Pessoa que reporta o erro. Este campo é automaticamente preenchido pelo Tracker. <br />
Ambiente (Environment) – Especifica qual o sistema operative, plataforma de software e/ou especificações de hardware, se aplicáveis ao erro em questão.<br />
<br />
'''Descrição''' (Description) – Uma descrição complete e concise do problema ou melhoramento. <br />
<br />
'''Base de dados''' (Database) – Campo opcional. Se for aplicável ao erro, identifica o tipo de base de dados utilizado. <br />
URL – Campo opcional. Se possivel, fornecer o endereço URL que demonstre um exemplo do erro. <br />
<br />
'''Responsável pelos testes''' (QA Assignee) – Usado para designer o responsável que irá fazer os testes. <br />
<br />
'''Versões reparadas''' (Fixed Version/s) – Versão do Moodle onde o erro esteve ou irá ser reparado. Basicamente deverá ser pensado em que notas de lançamento irão aparecer as alterações. Este campo é normalmente completado pelo programador quando o erro é dado como resolvido, ou então pelas equipas de desenvolvimento que afectaram os erros a determinada versão. Normalmente apenas uma versão é referida neste campo. Temos assim a indicação de qual a primeira versão onde a alteração irá ser visível. <br />
<br />
Exemplo: depois da versão 1.9 ser lançada, ser for reparado um erro na versão MOODLE_19_STABLE, ela irá ser marcada como reparada na versão 1.9.1. Se a reparação for a uma versão anterior, como por exemplo MOODLE_18_STABLE, deverá também ser adicionada na versão seguinte 1.8.x .<br />
<br />
Se for resolvido um erro como tudo menos “Reparado” (Não possível de reproduzir, Não Reparado, etc) deixar este campo em branco.<br />
<br />
Se for resolvido um erro anteriormente duplicado, deve ser criado um link para o duplicado do erro.<br />
<br />
Este campo é usado automaticamente para construir as notas de lançamento da versão (ver http://tracker.moodle.org/browse/MDL).<br />
<br />
'''Anexos''' (Attachment) - Opcional. Anexar um ficheiro que possa ajudar os programadores e responsáveis por testes a perceber melhor qual o erro. O tamanho máximo do anexo é de 512 Kb. <br />
<br />
'''Comentário''' (Comment) – O campo destinado aos comentários contém um registo detalhado de todas as alterações feitas a este erro. <br />
<br />
'''Resolution''' – Este campo apenas está disponível no momento de resolver ou fechar o erro. Deve então ser especificado no cógigo o modo como foi feita a resolução do erro. <br />
<br />
'''Reparado''' (Fixed) – O erro foi reparado; o código irá ser alterado no sistema CVS. Este código de resolução deve ser usado apenas quando forem feitas alterações ao código do Moodle.<br />
<br />
'''Impossível de reparar''' (Won't Fix) – O problema descrito diz respeito a um assunto que nunca irá ser reparado.<br />
<br />
'''Não é erro''' (Not a bug) – Não se trata de um erro; foi erradamente reportado. Use este código se o erro foi anteriormente reportado e reparado numa versão anterior do Moodle. <br />
<br />
'''Duplicado''' (Duplicate) – O problema é duplicado de outro problema já existente. <br />
<br />
'''Incompleto''' (Incomplete) – É necessária mais informação para a compreensão do problema. <br />
<br />
'''Impossível de reproduzir o erro''' (Can't Reproduce) – Todas as tentativas de reproduzir o erro falharam, ou não existia suficiente informação para que fosse possível a sua reprodução. A leitura do código não fornece pistas sobre a razão porque existe determinado comportamento. Se entretanto mais informações relevantes aparecerem, o assunto será novamente reaberto. <br />
<br />
'''Adiado''' (Deferred) – A resolução do problema será adiada para uma futura versão que será lançada. <br />
<br />
<br />
== Grupos do Tracker e Permissões ==<br />
<br />
<br />
Utilizadores normais [groupname=jira-user] - Este é o grupo por defeito. As novas contas de utilizador são colocadas neste grupo na altura da sua criação, e os utilizadores devem ser membros deste grupo para poderem submeter relatórios no Tracker. Os membros deste grupo podem pesquisar erros, criar erros novos, comentar erros, criar anexos, criar sub-tarefas, criar filtros, subscrever erros, e votar em erros. Os membros deste grupo podem também resolver erros, que é primeiramente uma maneira de fechar os erros que são já não relevantes (por exemplo duplicados, ou reportados por engano). Os utilizadores padrão podem configurar seu Tracker que o espaço de trabalho usando o botão "Configure your Issue Navigator". Esta característica permite que os utilizadores vejam as suas subscrições e listas de votos e controlem preferências, perfil, e senhas relativas ao Tracker.<br />
<br />
Programadores [groupname=jira-developer] - Os programadores podem fazer tudo o que utilizadores normais podem fazer. Além podem duplicar erros, subscrever erros, editar erros, ligar erros, e atribuir erros. Os membros deste grupo podem também usar a função Bulk Edit que permite a actualização bulk de múltiplos erros.<br />
<br />
Responsáveis por testes [groupname=moodle-testers] – Os responsáveis por executar testes, podem fazer tudo o que os programadores fazem.<br />
<br />
Grupos de segurança do Moodle [groupname=moodle-security] – Programadores acreditados e administradores que necessitam de trabalhar no sentido de desenvolver competências na área de segurança. <br />
<br />
<br />
'''Tipos de ligações'''<br />
<br />
Estão disponíveis os seguintes tipos de ligações:<br />
*Duplicados (duplicates) – duplicados são inevitáveis num projecto com a dimensão do Moodle. Ocorrem quando um utilizador reporta inconscientemente um erro relativo a um problema que já existe. Usa-se assim esta ligação para fazer a conexão entre o outro problema que estará descrito de modo mais compreensivo. Todos erros duplicados devem ser ligados.<br />
*Bloqueador (blockers) – usar esta ligação para a identificação de problemas que estão a bloquear a reparação de outros. <br />
*Clonadores (cloners) –nalguns casos um erros é propositadamente duplicado com o objectivo de reparar outro ramo de código – este sistema quase nunca é usado no projecto Moodle. <br />
*Dependência (dependency) – muitas vezes a reparação de uma falha está dependente de outra falha que deverá ser resolvida primeiro. Este tipo de ligações serve assim para definir a ordem pela qual deveram ser resolvidos erros que são dependentes entre si. <br />
*Correlações (relates) – é usado para identificar um erros que pode de alguma maneira estar relacionado com outro erro existente. <br />
<br />
'''Não receie ligar os erros entre si'''. As ligações são bidireccionais o que significa que existe um conceito que prevê os dois sentidos da ligação – isto afecta a maneira como os erros são mostrados. Esta é a razão pela qual de poderá ver “bloqueado /está bloqueado por” ou “duplicado/é duplicado de” na lista de ligações “Link Issue”. Não precisa de existir muita preocupação em colocar o tipo correcto de ligação, uma vez que todos funcionam de maneira semenhante.<br />
<br />
<br />
<br />
[[en:Tracker]]<br />
[[es:Sistema de bugs]]<br />
[[fr:Traqueur de bogues]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Tracker&diff=2530Tracker2008-05-22T11:21:16Z<p>Rubenback26: </p>
<hr />
<div><br />
== Tracker – Sistema de gestão de bugs do Moodle ==<br />
<br />
<br />
A detecção e reparação de bugs constituem um processo contínuo de controlo de qualidade. No caso do Moodle, esta detecção e reparação de bugs, por ser uma plataforma open-source, está aberta a todos quantos queiram participar, constituindo este facto uma vantagem em relação às plataformas proprietárias. O sistema que permite fazer esta detecção e posterior correcção de erros associados à plataforma Moodle chama-se Tracker.<br />
O ponto interessante do open-source está no facto em que todos os utilizadores interessados podem ajudar de várias formas, quer no código ou na detecção de erros, com o objectivo de trabalhar num produto que seja do agrado da comunidade.<br />
<br />
<br />
== Login no Tracker ==<br />
<br />
Caso seja um novo utilizador do Tracker, o processo de registo poderá ser realizado aqui. Recomenda-se aqui que o username usado seja o mesmo do site moode.org. <br />
Caso a conta de acesso ao Tracker não funcione, a mesma pode ser recuperada aqui: http://tracker.moodle.org<br />
<br />
'''Resumo: Como reportar um erro, um melhoramento, ou um pedido de funcionalidade'''<br />
<br />
1. Fazer o login na homepage do Moodle Tracker.<br />
<br />
2. Seleccionar “Create New Issue” no menu baixo do logótipo do Moodle Tracker.<br />
<br />
3. No passo 1, no menu desdobrável seleccionar o “Issue type”: Erro (bug), Nova Funcionalidade (New Feature), Tarefa (Task) ou Melhoramento (Improvement)<br />
<br />
4. No passo 2, será visível várias áreas desdobráveis em branco.<br />
<br />
#i. Resumo (Summary): Breve descrição do problema. O objectivo aqui é tentar fazer com que a descrição seja o mais precisa possível. A simples expressão do “Não funciona” não se revela de grande importância. È importante também pensar as palavras-chave que identificam o problema, para que o problema seja rapidamente encontrado pelos utilizadores pesquisarem pelo mesmo erro.<br />
<br />
#ii. Componentes (Components): usar a teclas Ctrl e com um click do rato seleccionar uma ou mais áreas do Moodle. Por exemplo, pode ser encontrado um erro numa funcionalidade que tenha impacto em vários módulos.<br />
<br />
#iii. Seleccionar a versão do Moodle, e caso não esteja listada por informação relativa á versão na descrição.<br />
<br />
#iv. O Ambiente (Enviroment) é para a informações relativas ao sistema operativo e outras informações. Ver guias gerais mais abaixo.<br />
#v. A Descrição (Descritpion) informa-nos acerca do assunto tratado. Informações sobre este tópico, mais abaixo.<br />
<br />
#vi. Base de Dados (Database), se não estiver na lista, por a informação relativa no campo Ambiente(Enviroment)<br />
<br />
<br />
'''Guia geral para a submissão de relatórios'''<br />
<br />
Um bom relatório deve incluir:<br />
#• Resumo do problema em uma ou 2 frases<br />
#• Descrição concreta e concisa do problema ou melhoramento em causa<br />
#• Deve ser também feita uma descrição passo-a-passo da sequência de passos a fazer com o objectivo de reproduzir o erro. Se possível, indicar o endereço para o que o programador consiga ver o erro apenas com um click.<br />
#• Resultados actuais: indicar o que é que a aplicação faz após os passos serem executados<br />
#• Resultados esperados: explicitar os resultados que são esperados, caso o erro não estivesse presente. É importante que a explicação seja bastante pormenorizada pois isso ajudará na resolução do erro, bem como no interface que poderá ser ajustado de forma a ser mais amigável.<br />
<br />
Se possível, incluir informação adicional que possa ser útil ao programador:<br />
#• Versão do Moodle (se a versão não se encontrar no menu desdobrável no topo do formulário, adicionar essa informação na descrição)<br />
#• Se existir uma mensagem de erro ou outra informação, quer nos logs do PHP ou do servidor web, inclua uma cópia dessa informação no relatório. Se for possível, ligar o modo “debug” na página configuração do Administrador com o objectivo de obter a melhor mensagem de erro possível.<br />
<br />
#• Os ecrãs capturados podem também ser uma grande ajuda, mas devem ser acompanhados de uma descrição.<br />
#• Fornecer as informações relativas à configuração do sistema operativo, base de dados, etc. Se o espaço disponível na secção Ambiente (Enviroment), pode ser feita a continuação na secção da descrição. Algumas das informações que neste caso podem ser relevantes, são:<br />
<br />
##o Sistema operativo do servidor e número de versão.<br />
##o Tipo de servidor e número de versão.<br />
##o Versão de PHP usada (e se é usado algum optimizador).<br />
##o Tipo de base de dados e número de versão.<br />
##o Tipo de sistema operativo do cliente e número de versão.<br />
##o Tipo e número de versão do browser utilizado.<br />
<br />
#• Não é necessário fornecer sempre todos os dados. Por exemplo, se for um problema de layout, será só necessário fornecer informação sobre o sistema operativo e browsers utilizados pelos clientes. Ficam aqui alguns exemplos:<br />
##o Detecção de um erro na última versão do HEAD do Moodle, a correr em PHP5.1.2/Apache 2.2.3 em Linux. A base de dados utilizada é Postgres 8.1.<br />
##o Existe um problema de renderização, utilizando o Internet Explorer 6.0 em Windows XP.<br />
<br />
Em resumo, deve fazer-se uma reunião de facto suficientemente boa para que outros utilizadores possam duplicar o problema.<br />
<br />
Aqui estão alguns exemplos de boas práticas na submissão de relatórios de erro: MDL-6030, MDL-5688, MDL-12505.<br />
Muitas vezes a parte difícil neste processo, não consiste na reparação do erro, mas sim na reprodução do mesmo por parte do programador. O programador tem assim de poder conseguir reproduzir o erro submetido, caso contrário nunca o poderá resolver.<br />
<br />
Bons relatórios são os que contêm informação o mais detalhada e especifica possível. <br />
Por exemplo, um relatório de erro que contenha apenas “ O feed RSS não suporta UTF-8” não ajuda em nada. O programador sabe que o UTF-8 e os RSS feeds são compatíveis. Além do mais o programador não faz ideia do que o utilizador vê no seu computador e porque submeteu o erro. Neste caso terá de ser dispendido mais tempo e esforço na determinação de qual será o problema.<br />
<br />
<br />
== O processo do Tracker ==<br />
<br />
<br />
'''Acompanhamento de novas matérias e melhorias'''<br />
<br />
Qualquer um com uma conta no Tracker pode acompanhar matérias que são submetidas. Acima estão descritas boas práticas sobre como escrever relatórios de erro de boa qualidade. É importante procurar no Tracker para determinar se o seu problema ou sugestão para a melhoria foram já objecto de relatório. Caso exista a intenção de adicionar mais informação (use a função do “comment”), voto para a edição, ou acompanhar para ver mais tarde (watch it).<br />
Receberá depois um email cada vez que for subscrito um novo erro novo ou forem feitas actualizações aos erros que foram relatados. Será também enviada uma notificação quando são feitas actualizações aos erros que foram marcados para serem acompanhados.<br />
<br />
Podem também ser monitorizados ou acompanhados, erros submetidos por outros utilizadores. Para fazer isto, abra o erro em questão, depois seleccione “Watch it” que se encontra na parte esquerda do painel de navegação. Para que outras pessoas sejam adicionadas para acompanhar problemas submetidos por nós, seleccionar a opção “Watching” que se encontra na parte esquerda do painel de navegação. Essas pessoas serão depois notificadas por correio electrónico cada vez que houver uma actualização ao problema.<br />
<br />
O Tracker fornece uma facilidade fazer o link entre matérias submetidas. Qualquer usuário registado no Tracker pode ligar matérias. Os tipos de ligação múltipla estão definidos no sistema; será solicitada a escolha de um tipo ao ser feito o link de erros. Veja [nome da secção da inserção] para lista detalhada de tipos da ligação.<br />
<br />
Vote em erros que você quer ver abordados no Moodle. Todos os utilizadores podem votar. Para votar para um erro específico, seleccione o erro, seleccionando depois “Vote for it” do painel de navegação esquerdo. Os programadores podem considerar o número dos votos que um erro tem para fazer a escolha entre dois ou mais erros.<br />
<br />
O painel (Dashboard) do Tracker é flexível e pode ser modificado conforme as áreas de interesse de cada utilizador. Para mais instruções acerca da configuração do Painel do Tracker clicar aqui.<br />
O Issue Navigator do Tracker é a ferramenta que permite encontrar e filtrar erros. Para mais instruções sobre o Issue Navigator clicar aqui.<br />
<br />
A função de pesquisa rápida (Quick Search) do Tracker está explicada aqui.<br />
<br />
'''Resolvendo assuntos no Tracker'''<br />
<br />
Só os programadores e responsáveis pelos testes ao Moodle têm permissão para mudar o estado dos erros no Tracker para “resolvido” ou “fechado” ("resolved" or "closed").<br />
<br />
Este é o processo geral que o programador irá seguir, quando mudar o estado de um assunto referido no Tracker:<br />
#1. Os assuntos são automaticamente atribuídos no momento da sua criação tendo como base o componente a que são relativos; caso os programadores ou os responsáveis do componente entendam, o assunto pode ser novamente atribuído a outro módulo<br />
#2. Os programadores reparam, modificam ou adicionam código e fazzem a verificação do CVS. O número que identifica o assunto no Tracker faz automaticamente a ligação entre a mudanças no CVS ao Tracker.<br />
#3. Os patchs estão anexos aos assuntos no Tracker para que possam ser analisados e depois possivelmente adicionados no CVS. <br />
#4. Devem ser acrescentados comentários no Tracker com a descrição da reparação feita. O estado do erro é depois alterado para Resolvido (Resolved).<br />
#5. O programador deve indicar em que versão do Moodle a alteração irá ser incluída usando o Fix Version/s. Deve depois ser indicado qual o ramo ou ramos nos quais a alteração foi verificada<br />
#6. A única excepção que pode existir na alteração de estado de um erro para Resolvido (Resolved) dá-se no caso de o programador entender que não existe valor em testar o assunto resolvido. Neste caso a alteração de estado será para Fechado (Closed).<br />
<br />
'''Testes á plataforma'''<br />
<br />
Todos os utilizadores são incentivados a serem participantes activos no que diz respeito a testar o Moodle. Qualquer pessoa que tenha um registo no Tracker pode registar, ver, comentar, votar, e acompanhar erros. Caso existam alguns erros, problemas, ideias para aperfeiçoamentos, o se existir o desejo de que alguma funcionalidade seja adicionada ao Moodle, o utilizador deve reportar isso no Tracker.<br />
<br />
Foi formalizado um grupo de pessoas responsáveis por fazer testes no Tracker que são responsáveis por verificar o rigor das alterações feitas pelos programadores. Este grupo de pessoas tem responsabilidades e autoridade no Tracker que vão além do utilizador comum. Além disto são utilizadores com grande conhecimento de toda a estrutura do Moodle, sendo também membros muito activos na comunidade Moodle. É claro que estes devem ter um nível suficiente em termos de atributos e conhecimentos necessários para os testes que realizam – a experiência é muito importante – mas também não pode ser esquecido que existem sempre utilizadores na comunidade dispostos a ajudar em qualquer eventualidade. Se quiser fazer parte da Equipa de Testes do Moodle, manifeste a sua intenção reportando-a no Tracker. Reporte a sua intenção em Moodle.org Sites Tracker project.<br />
<br />
'''Teste de erros no Tracker'''<br />
<br />
Este é o processo que a equipa de testes do Moodle deve seguir para alterar o estado dos erros de resolvidos (resolved) para fechados (closed).<br />
<br />
#• Os membros desta equipa testam os erros que se encontram no estado Resolvido (Resolved). Foram criados filtros global baseados em futuros lançamentos (ex. 1.9 Resolvido) para que a identificação seja feita de uma maneira mais facilitada.<br />
#• Usar o campo QA Assignee para fazer a identificação como inspector (membro responsável pelos testes) do erro.<br />
#• Uma boa ideia será subscrever todos os tópicos relativos aos erros que são testados (ex. todos os erros em que nós fomos responsáveis pela fase de testes).<br />
#• Caso o erro passar a fase de testes, alterar o estado do erro usando o botão “Fechar Assunto” (“Close Issue”). Devem ser adicionados comentários com a descrição do método usado para fazer os testes, todas as incorrecções encontradas, etc.<br />
#• Caso o erro não passe a fase de testes ou se houver o sentimento de que o erro não foi completamente reparado, deve fazer-se a alteração do seu estado através do botão “Reabrir Assunto” (“Reopen Issue”) de forma a este ficar novamente com a indicação que não está completamente resolvido. Certificar-se de que o problema é entregue ao programador correcto. Trabalhar com o programador no sentido de ser encontrada uma resolução que seja acertada para ambas as partes.<br />
<br />
#• Uma versão será dada como pronta quando todos os erros a ela relativos forem dados como estando fechados.<br />
#• Todos os erros resolvidos devem ser testados. Erros que no final tenham a indicação de reparados (fixed) representam erros sujo o seu código foi actualizado, e provavelmente representaram um maior desafio do que os erros que tenham no final a indicação de sendo duplicados, que não constituem um erro, ou que foi conseguido reproduzir esse erro. É aconselhável a certificação de que os erros foram finalizados com a indicação correcta. Infelizmente não é fácil alterar o código quando ele é posto no Tracker ( a única solução será reabrir e depois fechar o tópico).<br />
<br />
#• Os processos de teste devem ser discutidos sem receios com os programadores afectos ao erro. Muitas vezes um comentário chama logo a atenção do programador enquanto são notificados de todas as mudanças.<br />
Descrição detalhada de todos os grupos e campos do Tracker<br />
<br />
Em cada campo no Tracker é sempre apresentada uma pequena explicação.<br />
<br />
'''Projecto''' (Project) – Campo obrigatório - o Tracker é constituído por vários projectos. No presente existem 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. Escolha ‘moodle’ para erros/assuntos relacionados com o software moodle; escolha 'moodle.org sites' para erros/assuntos relacionados com tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, ou moodle.org; escolha 'Non-core contributed modules' para erros/assuntos relacionados com módulos.<br />
<br />
'''Tipo de assunto''' (Issue Type) - Campo obrigatório – os erros são classificados segundo as seguintes categorias:<br />
#• Erro (bug)- um problema que afecta o funcionamento correcto do Moodle.<br />
#• Melhoramento (Improvement) - uma melhoria a uma funcionalidade já existente no Moodle<br />
#• Nova funcionalidade (New Feature) – uma nova funcionalidade que tem ainda de ser desenvolvida<br />
#• Tarefa (Task) – uma tarefa que necessita de ser completada. Usualmente refere-se a trabalho que tem de ser executado fora do âmbito do produto.<br />
#• Sub-tarefa (Sub-task) – assuntos que por vezes são divididos em assuntos mais pequenos <br />
<br />
'''Sumário''' (Summary) - Campo obrigatório – uma descrição breve e concisa do problema.<br />
<br />
Nível de segurança (Security Level) – Campo opcional. Indica se o erro ou modificação tem implicações de segurança para o Moodle. Erros que tenham seriam implicações a nível de segurança, são reservados para a equipa de segurança do Moodle.<br />
<br />
'''Prioridade''' (Priority) – os erros têm os seguintes níveis de prioridade:<br />
#• Blocker – bloqueia o desenvolvimento e/ou trabalho de teste, a produção não pode continuar. <br />
#• Critical - Crashes, perdas de informação, fugas sérias a nível de memória. <br />
#• Major – perda importante de funcionalidade. <br />
#• Minor – perda de uma funcionalidade acessória, ou outro problema de fácil resolução<br />
#• Trivial – problema de nível cosmético como por exemplo erros ortográficos ou texto desalinhado <br />
<br />
'''Componentes''' (Components) – Campo obrigatório. Seleccionar a área do Moodle afectada pelo erro. Em caso de incerteza, seleccionar “Unknown”.<br />
<br />
'''Versão Afectada''' (Affects Version) – Campo obrigatório. Esta é a versão do Moodle na qual o erro foi encontrado. Esta informação é inserida pela pessoa que reporta o erro, e normalmente apenas uma versão é apontada. Inserir a versão actual no momento em que se reporta o melhoramento, tarefa ou nova funcionalidade ajudará avaliar o estado do produto quando o pedido foi feito.<br />
<br />
'''Afecto a''' (Assigned To) – Esta será a pessoa a que irá ser responsável pela resolução do problema. Este campo irá ser preenchido por programadores ou equipas responsáveis por módulos.<br />
<br />
'''Reportador''' (Reporter) – Pessoa que reporta o erro. Este campo é automaticamente preenchido pelo Tracker. <br />
Ambiente (Environment) – Especifica qual o sistema operative, plataforma de software e/ou especificações de hardware, se aplicáveis ao erro em questão.<br />
<br />
'''Descrição''' (Description) – Uma descrição complete e concise do problema ou melhoramento. <br />
<br />
'''Base de dados''' (Database) – Campo opcional. Se for aplicável ao erro, identifica o tipo de base de dados utilizado. <br />
URL – Campo opcional. Se possivel, fornecer o endereço URL que demonstre um exemplo do erro. <br />
<br />
'''Responsável pelos testes''' (QA Assignee) – Usado para designer o responsável que irá fazer os testes. <br />
<br />
'''Versões reparadas''' (Fixed Version/s) – Versão do Moodle onde o erro esteve ou irá ser reparado. Basicamente deverá ser pensado em que notas de lançamento irão aparecer as alterações. Este campo é normalmente completado pelo programador quando o erro é dado como resolvido, ou então pelas equipas de desenvolvimento que afectaram os erros a determinada versão. Normalmente apenas uma versão é referida neste campo. Temos assim a indicação de qual a primeira versão onde a alteração irá ser visível. <br />
<br />
Exemplo: depois da versão 1.9 ser lançada, ser for reparado um erro na versão MOODLE_19_STABLE, ela irá ser marcada como reparada na versão 1.9.1. Se a reparação for a uma versão anterior, como por exemplo MOODLE_18_STABLE, deverá também ser adicionada na versão seguinte 1.8.x .<br />
<br />
Se for resolvido um erro como tudo menos “Reparado” (Não possível de reproduzir, Não Reparado, etc) deixar este campo em branco.<br />
<br />
Se for resolvido um erro anteriormente duplicado, deve ser criado um link para o duplicado do erro.<br />
<br />
Este campo é usado automaticamente para construir as notas de lançamento da versão (ver http://tracker.moodle.org/browse/MDL).<br />
<br />
'''Anexos''' (Attachment) - Opcional. Anexar um ficheiro que possa ajudar os programadores e responsáveis por testes a perceber melhor qual o erro. O tamanho máximo do anexo é de 512 Kb. <br />
<br />
'''Comentário''' (Comment) – O campo destinado aos comentários contém um registo detalhado de todas as alterações feitas a este erro. <br />
<br />
'''Resolution''' – Este campo apenas está disponível no momento de resolver ou fechar o erro. Deve então ser especificado no cógigo o modo como foi feita a resolução do erro. <br />
<br />
'''Reparado''' (Fixed) – O erro foi reparado; o código irá ser alterado no sistema CVS. Este código de resolução deve ser usado apenas quando forem feitas alterações ao código do Moodle.<br />
<br />
'''Impossível de reparar''' (Won't Fix) – O problema descrito diz respeito a um assunto que nunca irá ser reparado.<br />
<br />
'''Não é erro''' (Not a bug) – Não se trata de um erro; foi erradamente reportado. Use este código se o erro foi anteriormente reportado e reparado numa versão anterior do Moodle. <br />
<br />
'''Duplicado''' (Duplicate) – O problema é duplicado de outro problema já existente. <br />
<br />
'''Incompleto''' (Incomplete) – É necessária mais informação para a compreensão do problema. <br />
<br />
'''Impossível de reproduzir o erro''' (Can't Reproduce) – Todas as tentativas de reproduzir o erro falharam, ou não existia suficiente informação para que fosse possível a sua reprodução. A leitura do código não fornece pistas sobre a razão porque existe determinado comportamento. Se entretanto mais informações relevantes aparecerem, o assunto será novamente reaberto. <br />
<br />
'''Adiado''' (Deferred) – A resolução do problema será adiada para uma futura versão que será lançada. <br />
<br />
<br />
== Grupos do Tracker e Permissões ==<br />
<br />
<br />
Utilizadores normais [groupname=jira-user] - Este é o grupo por defeito. As novas contas de utilizador são colocadas neste grupo na altura da sua criação, e os utilizadores devem ser membros deste grupo para poderem submeter relatórios no Tracker. Os membros deste grupo podem pesquisar erros, criar erros novos, comentar erros, criar anexos, criar sub-tarefas, criar filtros, subscrever erros, e votar em erros. Os membros deste grupo podem também resolver erros, que é primeiramente uma maneira de fechar os erros que são já não relevantes (por exemplo duplicados, ou reportados por engano). Os utilizadores padrão podem configurar seu Tracker que o espaço de trabalho usando o botão "Configure your Issue Navigator". Esta característica permite que os utilizadores vejam as suas subscrições e listas de votos e controlem preferências, perfil, e senhas relativas ao Tracker.<br />
<br />
Programadores [groupname=jira-developer] - Os programadores podem fazer tudo o que utilizadores normais podem fazer. Além podem duplicar erros, subscrever erros, editar erros, ligar erros, e atribuir erros. Os membros deste grupo podem também usar a função Bulk Edit que permite a actualização bulk de múltiplos erros.<br />
<br />
Responsáveis por testes [groupname=moodle-testers] – Os responsáveis por executar testes, podem fazer tudo o que os programadores fazem.<br />
<br />
Grupos de segurança do Moodle [groupname=moodle-security] – Programadores acreditados e administradores que necessitam de trabalhar no sentido de desenvolver competências na área de segurança. <br />
<br />
'''Tipos de ligações'''<br />
<br />
Estão disponíveis os seguintes tipos de ligações:<br />
#Duplicados (duplicates) – duplicados são inevitáveis num projecto com a dimensão do Moodle. Ocorrem quando um utilizador reporta inconscientemente um erro relativo a um problema que já existe. Usa-se assim esta ligação para fazer a conexão entre o outro problema que estará descrito de modo mais compreensivo. Todos erros duplicados devem ser ligados.<br />
#Bloqueador (blockers) – usar esta ligação para a identificação de problemas que estão a bloquear a reparação de outros. <br />
#Clonadores (cloners) –nalguns casos um erros é propositadamente duplicado com o objectivo de reparar outro ramo de código – este sistema quase nunca é usado no projecto Moodle. <br />
#Dependência (dependency) – muitas vezes a reparação de uma falha está dependente de outra falha que deverá ser resolvida primeiro. Este tipo de ligações serve assim para definir a ordem pela qual deveram ser resolvidos erros que são dependentes entre si. <br />
#Correlações (relates) – é usado para identificar um erros que pode de alguma maneira estar relacionado com outro erro existente. <br />
<br />
'''Não receie ligar os erros entre si'''. As ligações são bidireccionais o que significa que existe um conceito que prevê os dois sentidos da ligação – isto afecta a maneira como os erros são mostrados. Esta é a razão pela qual de poderá ver “bloqueado /está bloqueado por” ou “duplicado/é duplicado de” na lista de ligações “Link Issue”. Não precisa de existir muita preocupação em colocar o tipo correcto de ligação, uma vez que todos funcionam de maneira semenhante.</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2529CVS para programadores2008-05-18T11:13:47Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
<br />
• moodle – o código fonte principal do Moodle<br />
<br />
• lang – todos os packs de idiomas<br />
<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do cron nos sistemas Windows.<br />
<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/<br />
plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
<br />
[[Imagem:Merging.png]]<br />
<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name <br />
field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged <br />
from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[Category:Programador]]<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Utilizador:Ruben_Mamede&diff=2528Utilizador:Ruben Mamede2008-05-18T11:05:16Z<p>Rubenback26: </p>
<hr />
<div>"Informatics and Management" Student from ISCAC - Coimbra - Portugal<br />
<br />
<br />
<br />
Sou membro de um grupo de estudantes do curso de Informática de Gestão do Instituto Superior de Contabilidade e Administração de Coimbra, que está a trabalhar no desenvolvimento da plataforma e-learning desta instituição de ensino, bem como na criação de documentação técnica (em português) para programadores do Moodle.</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Utilizador:Ruben_Mamede&diff=2527Utilizador:Ruben Mamede2008-05-18T11:02:07Z<p>Rubenback26: </p>
<hr />
<div>"Informatics and Management" Student from ISCAC - Coimbra - Portugal<br />
<br />
<br />
<br />
Sou membro de um grupo de estudantes do curso de Informática de Gestão do Instituto Superior de Contabilidade e Administração de Coimbra, que está a trabalhar no desenvolvimento da plataforma e-learning desta instituição de ensino, bem como na criação de documentação técnica (em português) para programadores.</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2526CVS para programadores2008-05-18T10:33:15Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
<br />
• moodle – o código fonte principal do Moodle<br />
<br />
• lang – todos os packs de idiomas<br />
<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/<br />
plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
<br />
[[Imagem:Merging.png]]<br />
<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name <br />
field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged <br />
from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[Category:Programador]]<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2525CVS para programadores2008-05-17T18:27:40Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
<br />
• moodle – o código fonte principal do Moodle<br />
<br />
• lang – todos os packs de idiomas<br />
<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
<br />
[[Imagem:Merging.png]]<br />
<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[Category:Programador]]<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=manual_de_codigo&diff=2524manual de codigo2008-05-17T18:27:15Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento de código ==<br />
<br />
<br />
<br />
Qualquer projecto colaborativo precisa de consistência e estabilidade. A criação de código para a plataforma Moodle rege-se por um guia de desenvolvimento comum a toda a comunidade. Na verdade, algum do código mais antigo não respeita exactamente estas linhas orientadoras, no entanto, este ainda pode eventualmente ser submetido a alterações. Relativamente ao novo código, todo ele deverá respeitar estes padrões.<br />
<br />
<br />
== Regras Gerais ==<br />
<br />
<br />
1. Todos os ficheiros de código deverão usar a extensão .php.<br />
<br />
2. Todos os ficheiros de templates deverão usar a extensão .html.<br />
<br />
3. Todos os ficheiros de texto deverão usar o estilo Unix de formatação de texto.<br />
<br />
4. Todos os tags php devem estar preenchido (por exemplo <?php ?> ao invés de <? ?>).<br />
<br />
5. As referências de copyright já existentes deverão ser mantidas. Se necessário o criador de código pode criar as suas próprias referencias.<br />
<br />
6. Todos os ficheiros deverão conter o include do ficheiro principal config.php.<br />
<br />
7. Qualquer outra utilização de iclude’s/require’s deverá conter a localização completa precedida de $CFG->dirroot ou $CFG->libdir no caso de relative include’s.<br />
<br />
8. Cada ficheiro deverá verificar se o utilizador está correctamente autenticado através das funções require_login() e has_capability() ou require_capability().<br />
<br />
9. Todos os acessos às bases de dados deverão, sempre que possível, usar as funções definidas em lib/dmllib.php – estas permitem a compatibilidade com um vasto número de bases de dados e a grande maioria das operações desejadas. Se se pretender escrever código SQL então dever-se-á verificar se: funciona em qualquer plataforma; está restringido às funções específicas do seu código (geralmente um ficheiro lib.php); e está claramente comentado.<br />
<br />
10. Não deverão ser criadas/utilizadas variáveis globais excepto nos standards $CFG, $SESSION, $THEME, $SITE, $COURSE e $USER.<br />
<br />
11. Qualquer variável deverá ser inicializada ou pelo menos testada a sua existência utilizando isset() ou empty() antes de ser utilizada.<br />
<br />
12. Todas as strings devem ser traduzíveis - Os novos textos serão criados nos ficheiros "lang/pt_utf8" com palavras concisas em inglês (letra minúscula) e sua tradução completa em português, recuperandos no código utilizando as funções get_string() ou print_string(). Não se deverão apagar strings, desta forma garante-se a compatibilidade entre os diversos packs linguísticos.<br />
<br />
13. Não se devem usar as funções p() e s() nos prints(outputs) das strings linguísticas, estas não foram concebidas para utilizar html com tags. Para este efeito poderá ser utilizada a função echo().<br />
<br />
14. Todos os erros deverão ser visualizados utilizando a função print_error() para maximizar a tradução e ajudar o utilizador (acedendo automaticamente ao Moodle Docs).<br />
<br />
15. Todos os ficheiros de ajuda (help files) devem ser traduzíveis – Os novos textos devem ser criados na directoria "lang/pt_utf8/help" e acedidos através da função helpbutton(). Quando se pretender actualizar estes ficheiros:<br />
<br />
• Para uma pequena actualização, e no caso de a tradução antiga ser minimamente credível, pode-se efectuar a alteração mas esta deve ser submetida para translation@moodle.org.<br />
<br />
• Para alterações significativas, deve ser criado um novo ficheiro com um valor incrementado (por exemplo: filename2.html) de modo a que outros utilizadores possam compreender que se trata de uma nova versão do ficheiro em causa. Obviamente o novo código e os índices dos ficheiros de ajuda deverão ser actualizados de acordo com as versões mais recentes. <br />
<br />
16. A informação recebida a partir do browser (utilizando os métodos GET e POST) tem automaticamente as “magic_quotes” aplicadas (independentemente das definições PHP) pelo que podem ser inseridas de forma segura na base de dados. O resto da informação (obtida a partir de ficheiros ou de bases de dados) deve ser submetida à função addslashes() antes de ser inserida na base de dados. <br />
<br />
17. MUITO IMPORTANTE: Todos os textos dentro do Moodle, especialmente os que são introduzidos pelos utilizadores, devem ser mostrados utilizando a função format_text(). Esta assegura que o texto é filtrado e ajustado correctamente.<br />
<br />
18. As acções dos utilizadores devem ser gravadas utilizando a função add_to_log(). Estes dados são utilizados para as “Informações de actividade” e “Registos”.<br />
<br />
19. Para criar um link HTML, deverá utilizar a sua localização completa. Por exemplo $CFG->wwwroot/mod/blonk/view.php?id=99 em vez de view.php?id=99. Isto assegura, entre outras situações, que o código funciona se for chamado por um script noutra pasta.<br />
<br />
<br />
<br />
== Estilo do código ==<br />
<br />
<br />
É compreensível que possa ser frustrante e difícil alterar o estilo de programação de cada pessoa que já tenha trabalhado noutros projectos, mas se compararmos essa frustração com a das pessoas que mais a frente irão tentar encontrar o sentido do código do Moodle, verificamos que existe a necessidade de definir algumas regras de concepção de código para que a diversidade de estilos não se mostre um entrave a percepção do mesmo. Existem, como e natural, pontos fortes e pontos fracos do estilo adoptado mas é este estilo apresentado e que se deverá utilizar.<br />
<br />
1. Nunca utilizar tabulações ( TAB ) na identação do código. Utilizar sempre 4 espaços ( SPACE ).<br />
<br />
2. O nome das variáveis terá de ser de fácil leitura, palavras com significado em inglês e integralmente constituídas por letras minúsculas. Se eventualmente for necessário mais de uma palavra, estas deveram estar juntas tentando serem as mais pequenas possíveis. A definição de matrizes de objectos ( arrays ) deverá ser feita através de palavras no plural.<br />
<br />
Exemplos:<br />
<br />
B: $quiz<br />
B: $errorstring<br />
B: $assignments (for an array of objects)<br />
B: $i (but only in little loops)<br />
M: $Quiz<br />
M: $aReallyLongVariableNameWithoutAGoodReason<br />
M: $error_string<br />
<br />
Legenda: B – boa definição M – má definição<br />
<br />
3. Todas as constantes deverão estar definidas em Maiúsculas e o seu inicio será o nome do módulo. As palavras serão separadas por “underscores”.<br />
Exemplo:<br />
<br />
define("FORUM_MODE_FLATOLDEST", 1);<br />
<br />
4. Os nomes de funções terão de ser compostas por palavras simples em Inglês e começaram com o nome do módulo a que pertencem para evitar conflitos com outros módulos. Estas estarão separadas por “undercores”. Se possível, todos os parâmetros terão valor por defeito. Deverá certificar-se que não existe espaço entre o nome da função e o que se lhe segue (parêntesis).<br />
<br />
Exemplo:<br />
<br />
function forum_set_display_mode($mode=0) {<br />
global $USER, $CFG;<br />
<br />
if ($mode) {<br />
$USER->mode = $mode;<br />
} else if (empty($USER->mode)) {<br />
$USER->mode = $CFG->forum_displaymode;<br />
}<br />
}<br />
<br />
5. Todos os blocos de código terão de ser fechados com chavetas, independentemente de serem constituídos por apenas uma linha. O Moodle utiliza este estilo:<br />
<br />
if ($quiz->attempts) {<br />
if ($numattempts > $quiz->attempts) {<br />
error($strtoomanyattempts, "view.php?id=$cm->id");<br />
}<br />
}<br />
<br />
6. As strings deveram estar definidas entre pelicas ( caracter ‘ ), sempre que possivel.<br />
<br />
Exemplo:<br />
<br />
$var = 'some text without any variables';<br />
$var = 'with special characters like a new line '."\n";<br />
$var = 'a very, very long string with a '.$single.' variable in it';<br />
$var = "some $text with $many variables $within it";<br />
<br />
7. Todo o código desenvolvido deverá ser devidamente comentado, para que o desenrolar do código seja percebido tal como o objectivo de cada função e variáveis.<br />
<br />
• Todas as funções e classes deveram usar o formato phpDoc, para que a documentação seja automaticamente criada.<br />
<br />
• Os comentarios de uma so linha deverão utilizar //, antes da sua descrição e deverão estar alinhados com o código que comentam e na linha anterior.<br />
<br />
Exemplo:<br />
/**<br />
* The description should be first, with asterisks laid out exactly<br />
* like this example. If you want to refer to a another function,<br />
* do it like this: {@link clean_param()}. Then, add descriptions<br />
* for each parameter as follows.<br />
*<br />
* @param int $postid The PHP type is followed by the variable name<br />
* @param array $scale The PHP type is followed by the variable name<br />
* @param array $ratings The PHP type is followed by the variable name<br />
* @return mixed<br />
*/<br />
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {<br />
if (!$ratings) {<br />
$ratings = array(); // Initialize the empty array<br />
if ($rates = get_records("forum_ratings", "post", $postid)) {<br />
// Process each rating in turn<br />
foreach ($rates as $rate) {<br />
....etc<br />
<br />
8. O espaço em branco pode ser usado sem problema e pode ser bastante útil para separar partes de código tornando-o mais claro no geral. Geralmente, devera existir um espaço entre as chavetas de uma função e linhas normais de código, enquanto entre chavetas e variáveis ou funções não devera existir nenhum.<br />
<br />
Exemplo: <br />
<br />
foreach ($objects as $key => $thing) {<br />
process($thing);<br />
}<br />
<br />
if ($x == $y) {<br />
$a = $b;<br />
} else if ($x == $z) {<br />
$a = $c;<br />
} else {<br />
$a = $d;<br />
}<br />
<br />
9. Quando se efectuar uma copia de um determinado objecto, deverá ser sempre utilizada a função clone(), que originalmente esta disponível apenas em PHP5 (caso contrario terá apenas uma referencia para o primeiro objecto). Moodle garantira que este método funcionara, também em php4.<br />
<br />
Exemplo:<br />
<br />
M: $b = $a;<br />
B: $b = clone($a);<br />
<br />
Legenda: B – boa utilização M – má utilização<br />
<br />
Caso o que esteja a ser copiado não seja um objecto mas sim um conjunto de objectos (ex: arrays de objectos) deverá ser utilizada a função fullclone() de forma semelhante.<br />
<br />
<br />
== Estruturas das Bases de Dados ==<br />
<br />
<br />
Para a criação de tabelas devem ser tomadas em conta as seguintes regras de desenvolvimento:<br />
<br />
1. Todas as tabelas devem ter uma variável que é automaticamente incrementada que servirá para a identificação de campos (ex. id field (INT10))<br />
<br />
2. A tabela principal que contém instâncias de cada módulo, deve ter o mesmo nome do módulo (ex. questionário) e deve ainda conter obrigatoriamente os seguintes campos:<br />
<br />
• Id – como foi descrito na regra anterior<br />
<br />
• Course – id do curso a que cada instância pertence<br />
<br />
• Name – o nome completo de cada intância do módulo<br />
<br />
3. Outras tabelas que estejam associadas ao módulo que contenham matérias sobre “coisas” deveram ser chamadas questionário_coisas (de notar que o nome está no plural).<br />
<br />
4. Os nomes das tabelas e das colunas devem evitar conter quaisquer palavras que esteja já reservada nas bases de dados, pelo que se recomenda uma anterior verificação das mesmas.<br />
<br />
5. Os nomes das colunas devem ser sempre em letras minúsculas, devem ser nomes simples e pequenos, seguindo as mesmas regras aplicáveis para os nomes das variáveis.<br />
<br />
6. Sempre que for possível, as colunas que contenham referência a um campo id de outra tabela (ex. módulo) deve ter o nome módulo_id (Nota: esta convenção não foi utilizada nas tabelas de versões iniciais do moodle).<br />
<br />
7. Os campos booleanos devem ser implementados como campos de variáveis inteiras (ex INT4) que contêm os valores 0 ou 1, para suportarem uma posterior necessidade de essas variáveis conterem mais valores.<br />
<br />
8. Muitas das tabelas existentes deveram ter um campo que é modificado em função do passar do tempo (INT10) que será actualizada com a data actual que pode ser obtida com a função PHP time().<br />
<br />
9. Todos os campos devem ser inicializados com um valor inicial (que tenha sentido no contexto onde está inserido).<br />
<br />
10. Cada nome de tabela deve começar com o prefixo da base de dados ($CFG->prefixo). Na maioria dos casos, isto é automaticamente feito. Também, no Postgres, o nome de cada índice tem de começar com o mesmo prefixo.<br />
<br />
11. Para garantir a compatibilidade entre bases de dados devem ser seguidas simples regras como o uso da palavra chave AS (apenas de for necessário alias em tabelas\colunas, claro):<br />
<br />
• Não usar a palavra chave AS para alias de tabelas.<br />
<br />
• Usar a palavra chave AS para alias de colunas.<br />
<br />
12. Nunca criar UNIQUE KEYS (restrições) sem nenhuma razão específica. Em alternativa, usar UNIQUE INDEXes. No futuro, se for decidido adicionar integridade referencial no Moodle e for necessário UNIQUE KEYS, serão usadas, mas por agora este facto não se irá verificar. De notar ainda que o editor XMLDB permite especificar restrições XMLDB-only UNIQUE e FOREIGN (o que é um ponto positivo, com o objectivo de ter o XML bem definido) mas apenas os INDEXes sublinhados serão gerados na base de dados.<br />
<br />
13. Essas UNIQUE KEYS XMLDB-only (ler ponto anterior) apenas podem ser definidas se esse campo\campos vão ser alvo de alguma (também XMLDB-only) FOREIGN KEY. Caso contrário, devem ser criadas como UNIQUE INDEXes.<br />
<br />
14. As tabelas associadas com um bloco devem seguir a seguinte convenção na atribuição dos seus nomes: <br />
$CFG->prefix + "block_" + nome_do_bloco+ o_restante. Por exemplo assumindo que $CFG->prefix é ‘mdl_’, todas as tabelas do bloco “rss_cliente” devem começar com ‘mdl_block_rss_client’ (sendo possível que se adicione mais palavras no final, por ex. ‘mdl_block_rss_client_outratabela’…). Esta regra será 100% forçada com o Moodle 2.0, dando entretanto tempo aos programadores. Para mais informações consultar Task 6786.<br />
15. Nunca fazer mudanças em porções de código ESTÁVEIS. Este facto poderá provocar sérios erros quando os utilizadores actualizarem a sua versão estável para outra.<br />
<br />
16. Quando existir referência a uma variável inteira em consultas SQL, não por o valor entre pelicas. Por exemplo, get_records_select('question', "category=$catid") está correcto. Já o exemplo get_records_select('question', "category='$catid'") está incorrecto. Este caso pode dar origem a que sejam ocultados erros em que o valor de $catid não esteja definido. (Esta thread explica este caso).<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Coding]]<br />
[[es:Manual de Estilo de Código]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Planifica%C3%A7%C3%A3o&diff=2523Planificação2008-05-17T18:26:15Z<p>Rubenback26: </p>
<hr />
<div><br />
Esta planificação reúne a última informação sobre as novas funcionalidades do Moodle. Não é 100% real – as funcionalidades podem variar segundo os meios financeiros e humanos disponíveis.<br />
<br />
Quando sairá a próxima versão do Moodle?<br />
Esta questão recorrente tem uma resposta simples: quando estiver terminada !<br />
As datas mensionadas aqui são a titulo indicativo. Por vezes são respeitadas, mas é possível haver atrasos de dois meses. Se o atraso se prolonga, é por uma boa causa : melhorar a estabilidade e/ou introduzir novas funcionalidades.<br />
Não serve de nada colocar a questão com insistência com a aproximação das datas de saída previstas, é necessário saber ser paciente: antes que uma nova versão possa ser declarada como estável, é necessário no mínimo, que todos os erros que bloqueiam (e críticos se possível) sejam resolvidos ou colocados no Tracker.<br />
Se estiver pressionado e/ou deseja acelerar a saída da versão final, pode utilizar uma versão beta, se estiver perto de descobrir, declarar e eventualmente resolver os erros que estão no gestor de erros.<br />
<br />
<br />
== Versão 2.0 – Prevista para o inicio de 2009 ==<br />
<br />
<br />
'''Novas funcionalidades'''<br />
<br />
• O Moodle 2.0 necessitará do PHP 5.2<br />
PHP 5.2 mínimo, para certas melhorias não disponíveis em PHP 4, e permitindo assim limpar certas partes do código. Para mais informações, ver : gophp5.org<br />
<br />
• Melhorias na gestão de ficheiros – Moodle.com<br />
Ficheiros API – mantém um referencial de ficheiros interno e regista o acesso a este.<br />
Bases de dados API – permite aos utilizadores percorrer diferentes bases de dados externas a fim de escolher os ficheiros a integrar no Moodle.<br />
Portfolio API – permite que o conteúdo do Moodle seja capturado e depositado em depósitos externos.<br />
Estes três elementos são separados mas complementares, e por conseguinte serão desenvolvidos conjuntamente.<br />
<br />
• Actividades condicionais – Moodle.com<br />
Permitir as dependências e os caminhos forçados nas actividades (“Vocês não podem fazer isto sem terem terminado aquilo”).<br />
<br />
• Planos de formação e competências – Moodle.com e Google Summer of Code<br />
Apoia-se nos resultados/objectivos do Moodle 1.9 de modo que os indivíduos possam ter planos de formação que são actualizados quando os cursos são terminados.<br />
<br />
• Editor HTML 2.0<br />
Substituição do antigo editor HTMLarea por um novo, funcionando sobre mais navegadores, conforme XHTML estrito e permitindo uma melhor integração com os ficheiros API.<br />
<br />
• Interface de interconexão – Moodle.com e outros<br />
Facilita aos utilizadores a possibilidade de encontrar e navegar em outros sitemas e depósitos externos ao Moodle, aumentando a rede do Moodle de diversas maneiras.<br />
<br />
• Eliminação do antigo sistema de instalação/actualização da base de dados<br />
O antigo sistema de instalação e actualização da base de dados utilizado no Moodle < o 1.7 será completamente suprimido, dando-se suporte unicamente ao novo esquema de base de dados que utiliza XML introduzido com a versão 1.7. <br />
<br />
Nota: O Moodle 2.0 necessita do PHP 5.1 no mínimo, devido a certas melhorias não disponiveis em PHP 4.<br />
<br />
• Novo DataLib<br />
<br />
MDL-6605 O acesso à base de dados deve ser feito de modo que possamos : usar indicações preparadas em qualquer parte para aumentar a segurança e o desempenho, possamos colocar funções do datalib numa classe de modo a melhorar os testes de unidade (DB mock), e acabar com a necessidade de slashes no userspace. Isto causará ruptura na 3ª parte dos módulos (mas repará-los não deverá ser demasiado complicado).<br />
<br />
• Integração do Feedback do Módulo – Andrea Grab<br />
<br />
Melhorar e integrar como um módulo de base.<br />
<br />
• Novo módulo Wiki, baseado em NWiki - DFWikiteam-UPC<br />
<br />
Melhorar, limpar e integrar como um módulo básico.<br />
<br />
• Melhorias nos relatórios de testes - The Open University<br />
<br />
Melhorias principais aos relatórios do quis.<br />
<br />
• Blog 2.0<br />
<br />
Ajustar os comentários aos Blogs (MDL-8776), assim como o apoio dos blogs externos.<br />
<br />
• Serviço de mensagens 2.0<br />
<br />
Modificação do serviço de mensagens para utilizar plugins de entrada e saída, controlados pelos utilizadores.<br />
<br />
• Fios RSS protegidos<br />
<br />
RSS obscuros alimentam URLs usando as chaves confidenciais, controladas por usuários.<br />
<br />
• Mais Tags<br />
<br />
Tags para os cursos, as actividades outras coisas.<br />
<br />
<br />
<br />
== Esperem igualmente ==<br />
<br />
<br />
• Informação de estudo API<br />
<br />
API para integrar os sistemas externos de modo a gerar as irformações dos estudantes.<br />
<br />
• Exportação da Aprendizagem Do Projeto? - Moodle.com e l'Open University of The Netherlands.<br />
<br />
Está previsto haver um formato de exportação muito simples de um curso moodle para o formato IMS LD, para mostrar o conceito e para ajudar a comunidade a começar a habituar-se à IMS LD.<br />
<br />
• Integração de Turnitin - Dan Marsden com o apoio de Catalyst NZ<br />
<br />
• Melhorar a utilização<br />
<br />
Melhorar a ergonomia para os utilizadores (tanto novos como antigos), graças a um aumento de testes, a disponibilidade selectiva das funcionalidades, e da procura ( como os projectos GSOC).<br />
<br />
<br />
== Ver também ==<br />
<br />
<br />
Podem consultar as notas de actualização das versões que já saíram.<br />
O Histórico das versões, para conhecer as datas de saída de todas as versões do moodle.<br />
<br />
[[Category:Programador]]<br />
<br />
[[en:Roadmap]]<br />
[[es:Planificación]]<br />
[[fr:Planification]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Planifica%C3%A7%C3%A3o&diff=2522Planificação2008-05-17T18:23:18Z<p>Rubenback26: </p>
<hr />
<div><br />
<br />
Esta planificação reúne a última informação sobre as novas funcionalidades do Moodle. Não é 100% real – as funcionalidades podem variar segundo os meios financeiros e humanos disponíveis.<br />
<br />
Quando sairá a próxima versão do Moodle?<br />
Esta questão recorrente tem uma resposta simples: quando estiver terminada !<br />
As datas mensionadas aqui são a titulo indicativo. Por vezes são respeitadas, mas é possível haver atrasos de dois meses. Se o atraso se prolonga, é por uma boa causa : melhorar a estabilidade e/ou introduzir novas funcionalidades.<br />
Não serve de nada colocar a questão com insistência com a aproximação das datas de saída previstas, é necessário saber ser paciente: antes que uma nova versão possa ser declarada como estável, é necessário no mínimo, que todos os erros que bloqueiam (e críticos se possível) sejam resolvidos ou colocados no Tracker.<br />
Se estiver pressionado e/ou deseja acelerar a saída da versão final, pode utilizar uma versão beta, se estiver perto de descobrir, declarar e eventualmente resolver os erros que estão no gestor de erros.<br />
<br />
<br />
== Versão 2.0 – Prevista para o inicio de 2009 ==<br />
<br />
<br />
'''Novas funcionalidades'''<br />
<br />
• O Moodle 2.0 necessitará do PHP 5.2<br />
PHP 5.2 mínimo, para certas melhorias não disponíveis em PHP 4, e permitindo assim limpar certas partes do código. Para mais informações, ver : gophp5.org<br />
<br />
• Melhorias na gestão de ficheiros – Moodle.com<br />
Ficheiros API – mantém um referencial de ficheiros interno e regista o acesso a este.<br />
Bases de dados API – permite aos utilizadores percorrer diferentes bases de dados externas a fim de escolher os ficheiros a integrar no Moodle.<br />
Portfolio API – permite que o conteúdo do Moodle seja capturado e depositado em depósitos externos.<br />
Estes três elementos são separados mas complementares, e por conseguinte serão desenvolvidos conjuntamente.<br />
<br />
• Actividades condicionais – Moodle.com<br />
Permitir as dependências e os caminhos forçados nas actividades (“Vocês não podem fazer isto sem terem terminado aquilo”).<br />
<br />
• Planos de formação e competências – Moodle.com e Google Summer of Code<br />
Apoia-se nos resultados/objectivos do Moodle 1.9 de modo que os indivíduos possam ter planos de formação que são actualizados quando os cursos são terminados.<br />
<br />
• Editor HTML 2.0<br />
Substituição do antigo editor HTMLarea por um novo, funcionando sobre mais navegadores, conforme XHTML estrito e permitindo uma melhor integração com os ficheiros API.<br />
<br />
• Interface de interconexão – Moodle.com e outros<br />
Facilita aos utilizadores a possibilidade de encontrar e navegar em outros sitemas e depósitos externos ao Moodle, aumentando a rede do Moodle de diversas maneiras.<br />
<br />
• Eliminação do antigo sistema de instalação/actualização da base de dados<br />
O antigo sistema de instalação e actualização da base de dados utilizado no Moodle < o 1.7 será completamente suprimido, dando-se suporte unicamente ao novo esquema de base de dados que utiliza XML introduzido com a versão 1.7. <br />
<br />
Nota: O Moodle 2.0 necessita do PHP 5.1 no mínimo, devido a certas melhorias não disponiveis em PHP 4.<br />
<br />
• Novo DataLib<br />
<br />
MDL-6605 O acesso à base de dados deve ser feito de modo que possamos : usar indicações preparadas em qualquer parte para aumentar a segurança e o desempenho, possamos colocar funções do datalib numa classe de modo a melhorar os testes de unidade (DB mock), e acabar com a necessidade de slashes no userspace. Isto causará ruptura na 3ª parte dos módulos (mas repará-los não deverá ser demasiado complicado).<br />
<br />
• Integração do Feedback do Módulo – Andrea Grab<br />
<br />
Melhorar e integrar como um módulo de base.<br />
<br />
• Novo módulo Wiki, baseado em NWiki - DFWikiteam-UPC<br />
<br />
Melhorar, limpar e integrar como um módulo básico.<br />
<br />
• Melhorias nos relatórios de testes - The Open University<br />
<br />
Melhorias principais aos relatórios do quis.<br />
<br />
• Blog 2.0<br />
<br />
Ajustar os comentários aos Blogs (MDL-8776), assim como o apoio dos blogs externos.<br />
<br />
• Serviço de mensagens 2.0<br />
<br />
Modificação do serviço de mensagens para utilizar plugins de entrada e saída, controlados pelos utilizadores.<br />
<br />
• Fios RSS protegidos<br />
<br />
RSS obscuros alimentam URLs usando as chaves confidenciais, controladas por usuários.<br />
<br />
• Mais Tags<br />
<br />
Tags para os cursos, as actividades outras coisas.<br />
<br />
<br />
<br />
== Esperem igualmente ==<br />
<br />
<br />
• Informação de estudo API<br />
<br />
API para integrar os sistemas externos de modo a gerar as irformações dos estudantes.<br />
<br />
• Exportação da Aprendizagem Do Projeto? - Moodle.com e l'Open University of The Netherlands.<br />
<br />
Está previsto haver um formato de exportação muito simples de um curso moodle para o formato IMS LD, para mostrar o conceito e para ajudar a comunidade a começar a habituar-se à IMS LD.<br />
<br />
• Integração de Turnitin - Dan Marsden com o apoio de Catalyst NZ<br />
<br />
• Melhorar a utilização<br />
<br />
Melhorar a ergonomia para os utilizadores (tanto novos como antigos), graças a um aumento de testes, a disponibilidade selectiva das funcionalidades, e da procura ( como os projectos GSOC).<br />
<br />
<br />
== Ver também ==<br />
<br />
<br />
Podem consultar as notas de actualização das versões que já saíram.<br />
O Histórico das versões, para conhecer as datas de saída de todas as versões do moodle.</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=manual_de_codigo&diff=2521manual de codigo2008-05-17T18:15:25Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento de código ==<br />
<br />
<br />
<br />
Qualquer projecto colaborativo precisa de consistência e estabilidade. A criação de código para a plataforma Moodle rege-se por um guia de desenvolvimento comum a toda a comunidade. Na verdade, algum do código mais antigo não respeita exactamente estas linhas orientadoras, no entanto, este ainda pode eventualmente ser submetido a alterações. Relativamente ao novo código, todo ele deverá respeitar estes padrões.<br />
<br />
<br />
== Regras Gerais ==<br />
<br />
<br />
1. Todos os ficheiros de código deverão usar a extensão .php.<br />
<br />
2. Todos os ficheiros de templates deverão usar a extensão .html.<br />
<br />
3. Todos os ficheiros de texto deverão usar o estilo Unix de formatação de texto.<br />
<br />
4. Todos os tags php devem estar preenchido (por exemplo <?php ?> ao invés de <? ?>).<br />
<br />
5. As referências de copyright já existentes deverão ser mantidas. Se necessário o criador de código pode criar as suas próprias referencias.<br />
<br />
6. Todos os ficheiros deverão conter o include do ficheiro principal config.php.<br />
<br />
7. Qualquer outra utilização de iclude’s/require’s deverá conter a localização completa precedida de $CFG->dirroot ou $CFG->libdir no caso de relative include’s.<br />
<br />
8. Cada ficheiro deverá verificar se o utilizador está correctamente autenticado através das funções require_login() e has_capability() ou require_capability().<br />
<br />
9. Todos os acessos às bases de dados deverão, sempre que possível, usar as funções definidas em lib/dmllib.php – estas permitem a compatibilidade com um vasto número de bases de dados e a grande maioria das operações desejadas. Se se pretender escrever código SQL então dever-se-á verificar se: funciona em qualquer plataforma; está restringido às funções específicas do seu código (geralmente um ficheiro lib.php); e está claramente comentado.<br />
<br />
10. Não deverão ser criadas/utilizadas variáveis globais excepto nos standards $CFG, $SESSION, $THEME, $SITE, $COURSE e $USER.<br />
<br />
11. Qualquer variável deverá ser inicializada ou pelo menos testada a sua existência utilizando isset() ou empty() antes de ser utilizada.<br />
<br />
12. Todas as strings devem ser traduzíveis - Os novos textos serão criados nos ficheiros "lang/pt_utf8" com palavras concisas em inglês (letra minúscula) e sua tradução completa em português, recuperandos no código utilizando as funções get_string() ou print_string(). Não se deverão apagar strings, desta forma garante-se a compatibilidade entre os diversos packs linguísticos.<br />
<br />
13. Não se devem usar as funções p() e s() nos prints(outputs) das strings linguísticas, estas não foram concebidas para utilizar html com tags. Para este efeito poderá ser utilizada a função echo().<br />
<br />
14. Todos os erros deverão ser visualizados utilizando a função print_error() para maximizar a tradução e ajudar o utilizador (acedendo automaticamente ao Moodle Docs).<br />
<br />
15. Todos os ficheiros de ajuda (help files) devem ser traduzíveis – Os novos textos devem ser criados na directoria "lang/pt_utf8/help" e acedidos através da função helpbutton(). Quando se pretender actualizar estes ficheiros:<br />
<br />
• Para uma pequena actualização, e no caso de a tradução antiga ser minimamente credível, pode-se efectuar a alteração mas esta deve ser submetida para translation@moodle.org.<br />
<br />
• Para alterações significativas, deve ser criado um novo ficheiro com um valor incrementado (por exemplo: filename2.html) de modo a que outros utilizadores possam compreender que se trata de uma nova versão do ficheiro em causa. Obviamente o novo código e os índices dos ficheiros de ajuda deverão ser actualizados de acordo com as versões mais recentes. <br />
<br />
16. A informação recebida a partir do browser (utilizando os métodos GET e POST) tem automaticamente as “magic_quotes” aplicadas (independentemente das definições PHP) pelo que podem ser inseridas de forma segura na base de dados. O resto da informação (obtida a partir de ficheiros ou de bases de dados) deve ser submetida à função addslashes() antes de ser inserida na base de dados. <br />
<br />
17. MUITO IMPORTANTE: Todos os textos dentro do Moodle, especialmente os que são introduzidos pelos utilizadores, devem ser mostrados utilizando a função format_text(). Esta assegura que o texto é filtrado e ajustado correctamente.<br />
<br />
18. As acções dos utilizadores devem ser gravadas utilizando a função add_to_log(). Estes dados são utilizados para as “Informações de actividade” e “Registos”.<br />
<br />
19. Para criar um link HTML, deverá utilizar a sua localização completa. Por exemplo $CFG->wwwroot/mod/blonk/view.php?id=99 em vez de view.php?id=99. Isto assegura, entre outras situações, que o código funciona se for chamado por um script noutra pasta.<br />
<br />
<br />
<br />
== Estilo do código ==<br />
<br />
<br />
É compreensível que possa ser frustrante e difícil alterar o estilo de programação de cada pessoa que já tenha trabalhado noutros projectos, mas se compararmos essa frustração com a das pessoas que mais a frente irão tentar encontrar o sentido do código do Moodle, verificamos que existe a necessidade de definir algumas regras de concepção de código para que a diversidade de estilos não se mostre um entrave a percepção do mesmo. Existem, como e natural, pontos fortes e pontos fracos do estilo adoptado mas é este estilo apresentado e que se deverá utilizar.<br />
<br />
1. Nunca utilizar tabulações ( TAB ) na identação do código. Utilizar sempre 4 espaços ( SPACE ).<br />
<br />
2. O nome das variáveis terá de ser de fácil leitura, palavras com significado em inglês e integralmente constituídas por letras minúsculas. Se eventualmente for necessário mais de uma palavra, estas deveram estar juntas tentando serem as mais pequenas possíveis. A definição de matrizes de objectos ( arrays ) deverá ser feita através de palavras no plural.<br />
<br />
Exemplos:<br />
<br />
B: $quiz<br />
B: $errorstring<br />
B: $assignments (for an array of objects)<br />
B: $i (but only in little loops)<br />
M: $Quiz<br />
M: $aReallyLongVariableNameWithoutAGoodReason<br />
M: $error_string<br />
<br />
Legenda: B – boa definição M – má definição<br />
<br />
3. Todas as constantes deverão estar definidas em Maiúsculas e o seu inicio será o nome do módulo. As palavras serão separadas por “underscores”.<br />
Exemplo:<br />
<br />
define("FORUM_MODE_FLATOLDEST", 1);<br />
<br />
4. Os nomes de funções terão de ser compostas por palavras simples em Inglês e começaram com o nome do módulo a que pertencem para evitar conflitos com outros módulos. Estas estarão separadas por “undercores”. Se possível, todos os parâmetros terão valor por defeito. Deverá certificar-se que não existe espaço entre o nome da função e o que se lhe segue (parêntesis).<br />
<br />
Exemplo:<br />
<br />
function forum_set_display_mode($mode=0) {<br />
global $USER, $CFG;<br />
<br />
if ($mode) {<br />
$USER->mode = $mode;<br />
} else if (empty($USER->mode)) {<br />
$USER->mode = $CFG->forum_displaymode;<br />
}<br />
}<br />
<br />
5. Todos os blocos de código terão de ser fechados com chavetas, independentemente de serem constituídos por apenas uma linha. O Moodle utiliza este estilo:<br />
<br />
if ($quiz->attempts) {<br />
if ($numattempts > $quiz->attempts) {<br />
error($strtoomanyattempts, "view.php?id=$cm->id");<br />
}<br />
}<br />
<br />
6. As strings deveram estar definidas entre pelicas ( caracter ‘ ), sempre que possivel.<br />
<br />
Exemplo:<br />
<br />
$var = 'some text without any variables';<br />
$var = 'with special characters like a new line '."\n";<br />
$var = 'a very, very long string with a '.$single.' variable in it';<br />
$var = "some $text with $many variables $within it";<br />
<br />
7. Todo o código desenvolvido deverá ser devidamente comentado, para que o desenrolar do código seja percebido tal como o objectivo de cada função e variáveis.<br />
<br />
• Todas as funções e classes deveram usar o formato phpDoc, para que a documentação seja automaticamente criada.<br />
<br />
• Os comentarios de uma so linha deverão utilizar //, antes da sua descrição e deverão estar alinhados com o código que comentam e na linha anterior.<br />
<br />
Exemplo:<br />
/**<br />
* The description should be first, with asterisks laid out exactly<br />
* like this example. If you want to refer to a another function,<br />
* do it like this: {@link clean_param()}. Then, add descriptions<br />
* for each parameter as follows.<br />
*<br />
* @param int $postid The PHP type is followed by the variable name<br />
* @param array $scale The PHP type is followed by the variable name<br />
* @param array $ratings The PHP type is followed by the variable name<br />
* @return mixed<br />
*/<br />
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {<br />
if (!$ratings) {<br />
$ratings = array(); // Initialize the empty array<br />
if ($rates = get_records("forum_ratings", "post", $postid)) {<br />
// Process each rating in turn<br />
foreach ($rates as $rate) {<br />
....etc<br />
<br />
8. O espaço em branco pode ser usado sem problema e pode ser bastante útil para separar partes de código tornando-o mais claro no geral. Geralmente, devera existir um espaço entre as chavetas de uma função e linhas normais de código, enquanto entre chavetas e variáveis ou funções não devera existir nenhum.<br />
<br />
Exemplo: <br />
<br />
foreach ($objects as $key => $thing) {<br />
process($thing);<br />
}<br />
<br />
if ($x == $y) {<br />
$a = $b;<br />
} else if ($x == $z) {<br />
$a = $c;<br />
} else {<br />
$a = $d;<br />
}<br />
<br />
9. Quando se efectuar uma copia de um determinado objecto, deverá ser sempre utilizada a função clone(), que originalmente esta disponível apenas em PHP5 (caso contrario terá apenas uma referencia para o primeiro objecto). Moodle garantira que este método funcionara, também em php4.<br />
<br />
Exemplo:<br />
<br />
M: $b = $a;<br />
B: $b = clone($a);<br />
<br />
Legenda: B – boa utilização M – má utilização<br />
<br />
Caso o que esteja a ser copiado não seja um objecto mas sim um conjunto de objectos (ex: arrays de objectos) deverá ser utilizada a função fullclone() de forma semelhante.<br />
<br />
<br />
== Estruturas das Bases de Dados ==<br />
<br />
<br />
Para a criação de tabelas devem ser tomadas em conta as seguintes regras de desenvolvimento:<br />
<br />
1. Todas as tabelas devem ter uma variável que é automaticamente incrementada que servirá para a identificação de campos (ex. id field (INT10))<br />
<br />
2. A tabela principal que contém instâncias de cada módulo, deve ter o mesmo nome do módulo (ex. questionário) e deve ainda conter obrigatoriamente os seguintes campos:<br />
<br />
• Id – como foi descrito na regra anterior<br />
<br />
• Course – id do curso a que cada instância pertence<br />
<br />
• Name – o nome completo de cada intância do módulo<br />
<br />
3. Outras tabelas que estejam associadas ao módulo que contenham matérias sobre “coisas” deveram ser chamadas questionário_coisas (de notar que o nome está no plural).<br />
<br />
4. Os nomes das tabelas e das colunas devem evitar conter quaisquer palavras que esteja já reservada nas bases de dados, pelo que se recomenda uma anterior verificação das mesmas.<br />
<br />
5. Os nomes das colunas devem ser sempre em letras minúsculas, devem ser nomes simples e pequenos, seguindo as mesmas regras aplicáveis para os nomes das variáveis.<br />
<br />
6. Sempre que for possível, as colunas que contenham referência a um campo id de outra tabela (ex. módulo) deve ter o nome módulo_id (Nota: esta convenção não foi utilizada nas tabelas de versões iniciais do moodle).<br />
<br />
7. Os campos booleanos devem ser implementados como campos de variáveis inteiras (ex INT4) que contêm os valores 0 ou 1, para suportarem uma posterior necessidade de essas variáveis conterem mais valores.<br />
<br />
8. Muitas das tabelas existentes deveram ter um campo que é modificado em função do passar do tempo (INT10) que será actualizada com a data actual que pode ser obtida com a função PHP time().<br />
<br />
9. Todos os campos devem ser inicializados com um valor inicial (que tenha sentido no contexto onde está inserido).<br />
<br />
10. Cada nome de tabela deve começar com o prefixo da base de dados ($CFG->prefixo). Na maioria dos casos, isto é automaticamente feito. Também, no Postgres, o nome de cada índice tem de começar com o mesmo prefixo.<br />
<br />
11. Para garantir a compatibilidade entre bases de dados devem ser seguidas simples regras como o uso da palavra chave AS (apenas de for necessário alias em tabelas\colunas, claro):<br />
<br />
• Não usar a palavra chave AS para alias de tabelas.<br />
<br />
• Usar a palavra chave AS para alias de colunas.<br />
<br />
12. Nunca criar UNIQUE KEYS (restrições) sem nenhuma razão específica. Em alternativa, usar UNIQUE INDEXes. No futuro, se for decidido adicionar integridade referencial no Moodle e for necessário UNIQUE KEYS, serão usadas, mas por agora este facto não se irá verificar. De notar ainda que o editor XMLDB permite especificar restrições XMLDB-only UNIQUE e FOREIGN (o que é um ponto positivo, com o objectivo de ter o XML bem definido) mas apenas os INDEXes sublinhados serão gerados na base de dados.<br />
<br />
13. Essas UNIQUE KEYS XMLDB-only (ler ponto anterior) apenas podem ser definidas se esse campo\campos vão ser alvo de alguma (também XMLDB-only) FOREIGN KEY. Caso contrário, devem ser criadas como UNIQUE INDEXes.<br />
<br />
14. As tabelas associadas com um bloco devem seguir a seguinte convenção na atribuição dos seus nomes: <br />
$CFG->prefix + "block_" + nome_do_bloco+ o_restante. Por exemplo assumindo que $CFG->prefix é ‘mdl_’, todas as tabelas do bloco “rss_cliente” devem começar com ‘mdl_block_rss_client’ (sendo possível que se adicione mais palavras no final, por ex. ‘mdl_block_rss_client_outratabela’…). Esta regra será 100% forçada com o Moodle 2.0, dando entretanto tempo aos programadores. Para mais informações consultar Task 6786.<br />
15. Nunca fazer mudanças em porções de código ESTÁVEIS. Este facto poderá provocar sérios erros quando os utilizadores actualizarem a sua versão estável para outra.<br />
<br />
16. Quando existir referência a uma variável inteira em consultas SQL, não por o valor entre pelicas. Por exemplo, get_records_select('question', "category=$catid") está correcto. Já o exemplo get_records_select('question', "category='$catid'") está incorrecto. Este caso pode dar origem a que sejam ocultados erros em que o valor de $catid não esteja definido. (Esta thread explica este caso).<br />
<br />
[[en:Coding]]<br />
[[es:Manual de Estilo de Código]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=manual_de_codigo&diff=2520manual de codigo2008-05-17T18:14:53Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento de código ==<br />
<br />
<br />
<br />
Qualquer projecto colaborativo precisa de consistência e estabilidade. A criação de código para a plataforma Moodle rege-se por um guia de desenvolvimento comum a toda a comunidade. Na verdade, algum do código mais antigo não respeita exactamente estas linhas orientadoras, no entanto, este ainda pode eventualmente ser submetido a alterações. Relativamente ao novo código, todo ele deverá respeitar estes padrões.<br />
<br />
<br />
== Regras Gerais ==<br />
<br />
<br />
1. Todos os ficheiros de código deverão usar a extensão .php.<br />
<br />
2. Todos os ficheiros de templates deverão usar a extensão .html.<br />
<br />
3. Todos os ficheiros de texto deverão usar o estilo Unix de formatação de texto.<br />
<br />
4. Todos os tags php devem estar preenchido (por exemplo <?php ?> ao invés de <? ?>).<br />
<br />
5. As referências de copyright já existentes deverão ser mantidas. Se necessário o criador de código pode criar as suas próprias referencias.<br />
<br />
6. Todos os ficheiros deverão conter o include do ficheiro principal config.php.<br />
<br />
7. Qualquer outra utilização de iclude’s/require’s deverá conter a localização completa precedida de $CFG->dirroot ou $CFG->libdir no caso de relative include’s.<br />
<br />
8. Cada ficheiro deverá verificar se o utilizador está correctamente autenticado através das funções require_login() e has_capability() ou require_capability().<br />
<br />
9. Todos os acessos às bases de dados deverão, sempre que possível, usar as funções definidas em lib/dmllib.php – estas permitem a compatibilidade com um vasto número de bases de dados e a grande maioria das operações desejadas. Se se pretender escrever código SQL então dever-se-á verificar se: funciona em qualquer plataforma; está restringido às funções específicas do seu código (geralmente um ficheiro lib.php); e está claramente comentado.<br />
<br />
10. Não deverão ser criadas/utilizadas variáveis globais excepto nos standards $CFG, $SESSION, $THEME, $SITE, $COURSE e $USER.<br />
<br />
11. Qualquer variável deverá ser inicializada ou pelo menos testada a sua existência utilizando isset() ou empty() antes de ser utilizada.<br />
<br />
12. Todas as strings devem ser traduzíveis - Os novos textos serão criados nos ficheiros "lang/pt_utf8" com palavras concisas em inglês (letra minúscula) e sua tradução completa em português, recuperandos no código utilizando as funções get_string() ou print_string(). Não se deverão apagar strings, desta forma garante-se a compatibilidade entre os diversos packs linguísticos.<br />
<br />
13. Não se devem usar as funções p() e s() nos prints(outputs) das strings linguísticas, estas não foram concebidas para utilizar html com tags. Para este efeito poderá ser utilizada a função echo().<br />
<br />
14. Todos os erros deverão ser visualizados utilizando a função print_error() para maximizar a tradução e ajudar o utilizador (acedendo automaticamente ao Moodle Docs).<br />
<br />
15. Todos os ficheiros de ajuda (help files) devem ser traduzíveis – Os novos textos devem ser criados na directoria "lang/pt_utf8/help" e acedidos através da função helpbutton(). Quando se pretender actualizar estes ficheiros:<br />
<br />
• Para uma pequena actualização, e no caso de a tradução antiga ser minimamente credível, pode-se efectuar a alteração mas esta deve ser submetida para translation@moodle.org.<br />
<br />
• Para alterações significativas, deve ser criado um novo ficheiro com um valor incrementado (por exemplo: filename2.html) de modo a que outros utilizadores possam compreender que se trata de uma nova versão do ficheiro em causa. Obviamente o novo código e os índices dos ficheiros de ajuda deverão ser actualizados de acordo com as versões mais recentes. <br />
<br />
16. A informação recebida a partir do browser (utilizando os métodos GET e POST) tem automaticamente as “magic_quotes” aplicadas (independentemente das definições PHP) pelo que podem ser inseridas de forma segura na base de dados. O resto da informação (obtida a partir de ficheiros ou de bases de dados) deve ser submetida à função addslashes() antes de ser inserida na base de dados. <br />
<br />
17. MUITO IMPORTANTE: Todos os textos dentro do Moodle, especialmente os que são introduzidos pelos utilizadores, devem ser mostrados utilizando a função format_text(). Esta assegura que o texto é filtrado e ajustado correctamente.<br />
<br />
18. As acções dos utilizadores devem ser gravadas utilizando a função add_to_log(). Estes dados são utilizados para as “Informações de actividade” e “Registos”.<br />
<br />
19. Para criar um link HTML, deverá utilizar a sua localização completa. Por exemplo $CFG->wwwroot/mod/blonk/view.php?id=99 em vez de view.php?id=99. Isto assegura, entre outras situações, que o código funciona se for chamado por um script noutra pasta.<br />
<br />
<br />
<br />
== Estilo do código ==<br />
<br />
<br />
É compreensível que possa ser frustrante e difícil alterar o estilo de programação de cada pessoa que já tenha trabalhado noutros projectos, mas se compararmos essa frustração com a das pessoas que mais a frente irão tentar encontrar o sentido do código do Moodle, verificamos que existe a necessidade de definir algumas regras de concepção de código para que a diversidade de estilos não se mostre um entrave a percepção do mesmo. Existem, como e natural, pontos fortes e pontos fracos do estilo adoptado mas é este estilo apresentado e que se deverá utilizar.<br />
<br />
1. Nunca utilizar tabulações ( TAB ) na identação do código. Utilizar sempre 4 espaços ( SPACE ).<br />
<br />
2. O nome das variáveis terá de ser de fácil leitura, palavras com significado em inglês e integralmente constituídas por letras minúsculas. Se eventualmente for necessário mais de uma palavra, estas deveram estar juntas tentando serem as mais pequenas possíveis. A definição de matrizes de objectos ( arrays ) deverá ser feita através de palavras no plural.<br />
<br />
Exemplos:<br />
<br />
B: $quiz<br />
B: $errorstring<br />
B: $assignments (for an array of objects)<br />
B: $i (but only in little loops)<br />
M: $Quiz<br />
M: $aReallyLongVariableNameWithoutAGoodReason<br />
M: $error_string<br />
<br />
Legenda: B – boa definição M – má definição<br />
<br />
3. Todas as constantes deverão estar definidas em Maiúsculas e o seu inicio será o nome do módulo. As palavras serão separadas por “underscores”.<br />
Exemplo:<br />
<br />
define("FORUM_MODE_FLATOLDEST", 1);<br />
<br />
4. Os nomes de funções terão de ser compostas por palavras simples em Inglês e começaram com o nome do módulo a que pertencem para evitar conflitos com outros módulos. Estas estarão separadas por “undercores”. Se possível, todos os parâmetros terão valor por defeito. Deverá certificar-se que não existe espaço entre o nome da função e o que se lhe segue (parêntesis).<br />
<br />
Exemplo:<br />
<br />
function forum_set_display_mode($mode=0) {<br />
global $USER, $CFG;<br />
<br />
if ($mode) {<br />
$USER->mode = $mode;<br />
} else if (empty($USER->mode)) {<br />
$USER->mode = $CFG->forum_displaymode;<br />
}<br />
}<br />
<br />
5. Todos os blocos de código terão de ser fechados com chavetas, independentemente de serem constituídos por apenas uma linha. O Moodle utiliza este estilo:<br />
<br />
if ($quiz->attempts) {<br />
if ($numattempts > $quiz->attempts) {<br />
error($strtoomanyattempts, "view.php?id=$cm->id");<br />
}<br />
}<br />
<br />
6. As strings deveram estar definidas entre pelicas ( caracter ‘ ), sempre que possivel.<br />
<br />
Exemplo:<br />
<br />
$var = 'some text without any variables';<br />
$var = 'with special characters like a new line '."\n";<br />
$var = 'a very, very long string with a '.$single.' variable in it';<br />
$var = "some $text with $many variables $within it";<br />
<br />
7. Todo o código desenvolvido deverá ser devidamente comentado, para que o desenrolar do código seja percebido tal como o objectivo de cada função e variáveis.<br />
<br />
• Todas as funções e classes deveram usar o formato phpDoc, para que a documentação seja automaticamente criada.<br />
<br />
• Os comentarios de uma so linha deverão utilizar //, antes da sua descrição e deverão estar alinhados com o código que comentam e na linha anterior.<br />
<br />
Exemplo:<br />
/**<br />
* The description should be first, with asterisks laid out exactly<br />
* like this example. If you want to refer to a another function,<br />
* do it like this: {@link clean_param()}. Then, add descriptions<br />
* for each parameter as follows.<br />
*<br />
* @param int $postid The PHP type is followed by the variable name<br />
* @param array $scale The PHP type is followed by the variable name<br />
* @param array $ratings The PHP type is followed by the variable name<br />
* @return mixed<br />
*/<br />
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {<br />
if (!$ratings) {<br />
$ratings = array(); // Initialize the empty array<br />
if ($rates = get_records("forum_ratings", "post", $postid)) {<br />
// Process each rating in turn<br />
foreach ($rates as $rate) {<br />
....etc<br />
<br />
8. O espaço em branco pode ser usado sem problema e pode ser bastante útil para separar partes de código tornando-o mais claro no geral. Geralmente, devera existir um espaço entre as chavetas de uma função e linhas normais de código, enquanto entre chavetas e variáveis ou funções não devera existir nenhum.<br />
<br />
Exemplo: <br />
<br />
foreach ($objects as $key => $thing) {<br />
process($thing);<br />
}<br />
<br />
if ($x == $y) {<br />
$a = $b;<br />
} else if ($x == $z) {<br />
$a = $c;<br />
} else {<br />
$a = $d;<br />
}<br />
<br />
9. Quando se efectuar uma copia de um determinado objecto, deverá ser sempre utilizada a função clone(), que originalmente esta disponível apenas em PHP5 (caso contrario terá apenas uma referencia para o primeiro objecto). Moodle garantira que este método funcionara, também em php4.<br />
<br />
Exemplo:<br />
<br />
M: $b = $a;<br />
B: $b = clone($a);<br />
<br />
Legenda: B – boa utilização M – má utilização<br />
<br />
Caso o que esteja a ser copiado não seja um objecto mas sim um conjunto de objectos (ex: arrays de objectos) deverá ser utilizada a função fullclone() de forma semelhante.<br />
<br />
<br />
== Estruturas das Bases de Dados ==<br />
<br />
<br />
Para a criação de tabelas devem ser tomadas em conta as seguintes regras de desenvolvimento:<br />
<br />
1. Todas as tabelas devem ter uma variável que é automaticamente incrementada que servirá para a identificação de campos (ex. id field (INT10))<br />
<br />
2. A tabela principal que contém instâncias de cada módulo, deve ter o mesmo nome do módulo (ex. questionário) e deve ainda conter obrigatoriamente os seguintes campos:<br />
<br />
• Id – como foi descrito na regra anterior<br />
<br />
• Course – id do curso a que cada instância pertence<br />
<br />
• Name – o nome completo de cada intância do módulo<br />
<br />
3. Outras tabelas que estejam associadas ao módulo que contenham matérias sobre “coisas” deveram ser chamadas questionário_coisas (de notar que o nome está no plural).<br />
<br />
4. Os nomes das tabelas e das colunas devem evitar conter quaisquer palavras que esteja já reservada nas bases de dados, pelo que se recomenda uma anterior verificação das mesmas.<br />
<br />
5. Os nomes das colunas devem ser sempre em letras minúsculas, devem ser nomes simples e pequenos, seguindo as mesmas regras aplicáveis para os nomes das variáveis.<br />
<br />
6. Sempre que for possível, as colunas que contenham referência a um campo id de outra tabela (ex. módulo) deve ter o nome módulo_id (Nota: esta convenção não foi utilizada nas tabelas de versões iniciais do moodle).<br />
<br />
7. Os campos booleanos devem ser implementados como campos de variáveis inteiras (ex INT4) que contêm os valores 0 ou 1, para suportarem uma posterior necessidade de essas variáveis conterem mais valores.<br />
<br />
8. Muitas das tabelas existentes deveram ter um campo que é modificado em função do passar do tempo (INT10) que será actualizada com a data actual que pode ser obtida com a função PHP time().<br />
<br />
9. Todos os campos devem ser inicializados com um valor inicial (que tenha sentido no contexto onde está inserido).<br />
<br />
10. Cada nome de tabela deve começar com o prefixo da base de dados ($CFG->prefixo). Na maioria dos casos, isto é automaticamente feito. Também, no Postgres, o nome de cada índice tem de começar com o mesmo prefixo.<br />
<br />
11. Para garantir a compatibilidade entre bases de dados devem ser seguidas simples regras como o uso da palavra chave AS (apenas de for necessário alias em tabelas\colunas, claro):<br />
<br />
• Não usar a palavra chave AS para alias de tabelas.<br />
<br />
• Usar a palavra chave AS para alias de colunas.<br />
<br />
12. Nunca criar UNIQUE KEYS (restrições) sem nenhuma razão específica. Em alternativa, usar UNIQUE INDEXes. No futuro, se for decidido adicionar integridade referencial no Moodle e for necessário UNIQUE KEYS, serão usadas, mas por agora este facto não se irá verificar. De notar ainda que o editor XMLDB permite especificar restrições XMLDB-only UNIQUE e FOREIGN (o que é um ponto positivo, com o objectivo de ter o XML bem definido) mas apenas os INDEXes sublinhados serão gerados na base de dados.<br />
<br />
13. Essas UNIQUE KEYS XMLDB-only (ler ponto anterior) apenas podem ser definidas se esse campo\campos vão ser alvo de alguma (também XMLDB-only) FOREIGN KEY. Caso contrário, devem ser criadas como UNIQUE INDEXes.<br />
<br />
14. As tabelas associadas com um bloco devem seguir a seguinte convenção na atribuição dos seus nomes: <br />
$CFG->prefix + "block_" + nome_do_bloco+ o_restante. Por exemplo assumindo que $CFG->prefix é ‘mdl_’, todas as tabelas do bloco “rss_cliente” devem começar com ‘mdl_block_rss_client’ (sendo possível que se adicione mais palavras no final, por ex. ‘mdl_block_rss_client_outratabela’…). Esta regra será 100% forçada com o Moodle 2.0, dando entretanto tempo aos programadores. Para mais informações consultar Task 6786.<br />
15. Nunca fazer mudanças em porções de código ESTÁVEIS. Este facto poderá provocar sérios erros quando os utilizadores actualizarem a sua versão estável para outra.<br />
<br />
16. Quando existir referência a uma variável inteira em consultas SQL, não por o valor entre pelicas. Por exemplo, get_records_select('question', "category=$catid") está correcto. Já o exemplo get_records_select('question', "category='$catid'") está incorrecto. Este caso pode dar origem a que sejam ocultados erros em que o valor de $catid não esteja definido. (Esta thread explica este caso).<br />
<br />
[[en:Coding]]<br />
[[es:Manual de Estilo de Código]]<br />
[[ja:コーディング]]<br />
[[zh:代码指南]]<br />
[[pl:Kodowanie]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=manual_de_codigo&diff=2519manual de codigo2008-05-17T17:58:38Z<p>Rubenback26: </p>
<hr />
<div><br />
== Desenvolvimento de código ==<br />
<br />
<br />
<br />
Qualquer projecto colaborativo precisa de consistência e estabilidade. A criação de código para a plataforma Moodle rege-se por um guia de desenvolvimento comum a toda a comunidade. Na verdade, algum do código mais antigo não respeita exactamente estas linhas orientadoras, no entanto, este ainda pode eventualmente ser submetido a alterações. Relativamente ao novo código, todo ele deverá respeitar estes padrões.<br />
<br />
<br />
== Regras Gerais ==<br />
<br />
<br />
1. Todos os ficheiros de código deverão usar a extensão .php.<br />
<br />
2. Todos os ficheiros de templates deverão usar a extensão .html.<br />
<br />
3. Todos os ficheiros de texto deverão usar o estilo Unix de formatação de texto.<br />
<br />
4. Todos os tags php devem estar preenchido (por exemplo <?php ?> ao invés de <? ?>).<br />
<br />
5. As referências de copyright já existentes deverão ser mantidas. Se necessário o criador de código pode criar as suas próprias referencias.<br />
<br />
6. Todos os ficheiros deverão conter o include do ficheiro principal config.php.<br />
<br />
7. Qualquer outra utilização de iclude’s/require’s deverá conter a localização completa precedida de $CFG->dirroot ou $CFG->libdir no caso de relative include’s.<br />
<br />
8. Cada ficheiro deverá verificar se o utilizador está correctamente autenticado através das funções require_login() e has_capability() ou require_capability().<br />
<br />
9. Todos os acessos às bases de dados deverão, sempre que possível, usar as funções definidas em lib/dmllib.php – estas permitem a compatibilidade com um vasto número de bases de dados e a grande maioria das operações desejadas. Se se pretender escrever código SQL então dever-se-á verificar se: funciona em qualquer plataforma; está restringido às funções específicas do seu código (geralmente um ficheiro lib.php); e está claramente comentado.<br />
<br />
10. Não deverão ser criadas/utilizadas variáveis globais excepto nos standards $CFG, $SESSION, $THEME, $SITE, $COURSE e $USER.<br />
<br />
11. Qualquer variável deverá ser inicializada ou pelo menos testada a sua existência utilizando isset() ou empty() antes de ser utilizada.<br />
<br />
12. Todas as strings devem ser traduzíveis - Os novos textos serão criados nos ficheiros "lang/pt_utf8" com palavras concisas em inglês (letra minúscula) e sua tradução completa em português, recuperandos no código utilizando as funções get_string() ou print_string(). Não se deverão apagar strings, desta forma garante-se a compatibilidade entre os diversos packs linguísticos.<br />
<br />
13. Não se devem usar as funções p() e s() nos prints(outputs) das strings linguísticas, estas não foram concebidas para utilizar html com tags. Para este efeito poderá ser utilizada a função echo().<br />
<br />
14. Todos os erros deverão ser visualizados utilizando a função print_error() para maximizar a tradução e ajudar o utilizador (acedendo automaticamente ao Moodle Docs).<br />
<br />
15. Todos os ficheiros de ajuda (help files) devem ser traduzíveis – Os novos textos devem ser criados na directoria "lang/pt_utf8/help" e acedidos através da função helpbutton(). Quando se pretender actualizar estes ficheiros:<br />
<br />
• Para uma pequena actualização, e no caso de a tradução antiga ser minimamente credível, pode-se efectuar a alteração mas esta deve ser submetida para translation@moodle.org.<br />
<br />
• Para alterações significativas, deve ser criado um novo ficheiro com um valor incrementado (por exemplo: filename2.html) de modo a que outros utilizadores possam compreender que se trata de uma nova versão do ficheiro em causa. Obviamente o novo código e os índices dos ficheiros de ajuda deverão ser actualizados de acordo com as versões mais recentes. <br />
<br />
16. A informação recebida a partir do browser (utilizando os métodos GET e POST) tem automaticamente as “magic_quotes” aplicadas (independentemente das definições PHP) pelo que podem ser inseridas de forma segura na base de dados. O resto da informação (obtida a partir de ficheiros ou de bases de dados) deve ser submetida à função addslashes() antes de ser inserida na base de dados. <br />
<br />
17. MUITO IMPORTANTE: Todos os textos dentro do Moodle, especialmente os que são introduzidos pelos utilizadores, devem ser mostrados utilizando a função format_text(). Esta assegura que o texto é filtrado e ajustado correctamente.<br />
<br />
18. As acções dos utilizadores devem ser gravadas utilizando a função add_to_log(). Estes dados são utilizados para as “Informações de actividade” e “Registos”.<br />
<br />
19. Para criar um link HTML, deverá utilizar a sua localização completa. Por exemplo $CFG->wwwroot/mod/blonk/view.php?id=99 em vez de view.php?id=99. Isto assegura, entre outras situações, que o código funciona se for chamado por um script noutra pasta.<br />
<br />
<br />
<br />
== Estilo do código ==<br />
<br />
<br />
É compreensível que possa ser frustrante e difícil alterar o estilo de programação de cada pessoa que já tenha trabalhado noutros projectos, mas se compararmos essa frustração com a das pessoas que mais a frente irão tentar encontrar o sentido do código do Moodle, verificamos que existe a necessidade de definir algumas regras de concepção de código para que a diversidade de estilos não se mostre um entrave a percepção do mesmo. Existem, como e natural, pontos fortes e pontos fracos do estilo adoptado mas é este estilo apresentado e que se deverá utilizar.<br />
<br />
1. Nunca utilizar tabulações ( TAB ) na identação do código. Utilizar sempre 4 espaços ( SPACE ).<br />
<br />
2. O nome das variáveis terá de ser de fácil leitura, palavras com significado em inglês e integralmente constituídas por letras minúsculas. Se eventualmente for necessário mais de uma palavra, estas deveram estar juntas tentando serem as mais pequenas possíveis. A definição de matrizes de objectos ( arrays ) deverá ser feita através de palavras no plural.<br />
<br />
Exemplos:<br />
<br />
B: $quiz<br />
B: $errorstring<br />
B: $assignments (for an array of objects)<br />
B: $i (but only in little loops)<br />
M: $Quiz<br />
M: $aReallyLongVariableNameWithoutAGoodReason<br />
M: $error_string<br />
<br />
Legenda: B – boa definição M – má definição<br />
<br />
3. Todas as constantes deverão estar definidas em Maiúsculas e o seu inicio será o nome do módulo. As palavras serão separadas por “underscores”.<br />
Exemplo:<br />
<br />
define("FORUM_MODE_FLATOLDEST", 1);<br />
<br />
4. Os nomes de funções terão de ser compostas por palavras simples em Inglês e começaram com o nome do módulo a que pertencem para evitar conflitos com outros módulos. Estas estarão separadas por “undercores”. Se possível, todos os parâmetros terão valor por defeito. Deverá certificar-se que não existe espaço entre o nome da função e o que se lhe segue (parêntesis).<br />
<br />
Exemplo:<br />
<br />
function forum_set_display_mode($mode=0) {<br />
global $USER, $CFG;<br />
<br />
if ($mode) {<br />
$USER->mode = $mode;<br />
} else if (empty($USER->mode)) {<br />
$USER->mode = $CFG->forum_displaymode;<br />
}<br />
}<br />
<br />
5. Todos os blocos de código terão de ser fechados com chavetas, independentemente de serem constituídos por apenas uma linha. O Moodle utiliza este estilo:<br />
<br />
if ($quiz->attempts) {<br />
if ($numattempts > $quiz->attempts) {<br />
error($strtoomanyattempts, "view.php?id=$cm->id");<br />
}<br />
}<br />
<br />
6. As strings deveram estar definidas entre pelicas ( caracter ‘ ), sempre que possivel.<br />
<br />
Exemplo:<br />
<br />
$var = 'some text without any variables';<br />
$var = 'with special characters like a new line '."\n";<br />
$var = 'a very, very long string with a '.$single.' variable in it';<br />
$var = "some $text with $many variables $within it";<br />
<br />
7. Todo o código desenvolvido deverá ser devidamente comentado, para que o desenrolar do código seja percebido tal como o objectivo de cada função e variáveis.<br />
<br />
• Todas as funções e classes deveram usar o formato phpDoc, para que a documentação seja automaticamente criada.<br />
<br />
• Os comentarios de uma so linha deverão utilizar //, antes da sua descrição e deverão estar alinhados com o código que comentam e na linha anterior.<br />
<br />
Exemplo:<br />
/**<br />
* The description should be first, with asterisks laid out exactly<br />
* like this example. If you want to refer to a another function,<br />
* do it like this: {@link clean_param()}. Then, add descriptions<br />
* for each parameter as follows.<br />
*<br />
* @param int $postid The PHP type is followed by the variable name<br />
* @param array $scale The PHP type is followed by the variable name<br />
* @param array $ratings The PHP type is followed by the variable name<br />
* @return mixed<br />
*/<br />
function forum_get_ratings_mean($postid, $scale, $ratings=NULL) {<br />
if (!$ratings) {<br />
$ratings = array(); // Initialize the empty array<br />
if ($rates = get_records("forum_ratings", "post", $postid)) {<br />
// Process each rating in turn<br />
foreach ($rates as $rate) {<br />
....etc<br />
<br />
8. O espaço em branco pode ser usado sem problema e pode ser bastante útil para separar partes de código tornando-o mais claro no geral. Geralmente, devera existir um espaço entre as chavetas de uma função e linhas normais de código, enquanto entre chavetas e variáveis ou funções não devera existir nenhum.<br />
<br />
Exemplo: <br />
<br />
foreach ($objects as $key => $thing) {<br />
process($thing);<br />
}<br />
<br />
if ($x == $y) {<br />
$a = $b;<br />
} else if ($x == $z) {<br />
$a = $c;<br />
} else {<br />
$a = $d;<br />
}<br />
<br />
9. Quando se efectuar uma copia de um determinado objecto, deverá ser sempre utilizada a função clone(), que originalmente esta disponível apenas em PHP5 (caso contrario terá apenas uma referencia para o primeiro objecto). Moodle garantira que este método funcionara, também em php4.<br />
<br />
Exemplo:<br />
<br />
M: $b = $a;<br />
B: $b = clone($a);<br />
<br />
Legenda: B – boa utilização M – má utilização<br />
<br />
Caso o que esteja a ser copiado não seja um objecto mas sim um conjunto de objectos (ex: arrays de objectos) deverá ser utilizada a função fullclone() de forma semelhante.<br />
<br />
<br />
== Estruturas das Bases de Dados ==<br />
<br />
<br />
Para a criação de tabelas devem ser tomadas em conta as seguintes regras de desenvolvimento:<br />
<br />
1. Todas as tabelas devem ter uma variável que é automaticamente incrementada que servirá para a identificação de campos (ex. id field (INT10))<br />
<br />
2. A tabela principal que contém instâncias de cada módulo, deve ter o mesmo nome do módulo (ex. questionário) e deve ainda conter obrigatoriamente os seguintes campos:<br />
<br />
• Id – como foi descrito na regra anterior<br />
<br />
• Course – id do curso a que cada instância pertence<br />
<br />
• Name – o nome completo de cada intância do módulo<br />
<br />
3. Outras tabelas que estejam associadas ao módulo que contenham matérias sobre “coisas” deveram ser chamadas questionário_coisas (de notar que o nome está no plural).<br />
<br />
4. Os nomes das tabelas e das colunas devem evitar conter quaisquer palavras que esteja já reservada nas bases de dados, pelo que se recomenda uma anterior verificação das mesmas.<br />
<br />
5. Os nomes das colunas devem ser sempre em letras minúsculas, devem ser nomes simples e pequenos, seguindo as mesmas regras aplicáveis para os nomes das variáveis.<br />
<br />
6. Sempre que for possível, as colunas que contenham referência a um campo id de outra tabela (ex. módulo) deve ter o nome módulo_id (Nota: esta convenção não foi utilizada nas tabelas de versões iniciais do moodle).<br />
<br />
7. Os campos booleanos devem ser implementados como campos de variáveis inteiras (ex INT4) que contêm os valores 0 ou 1, para suportarem uma posterior necessidade de essas variáveis conterem mais valores.<br />
<br />
8. Muitas das tabelas existentes deveram ter um campo que é modificado em função do passar do tempo (INT10) que será actualizada com a data actual que pode ser obtida com a função PHP time().<br />
<br />
9. Todos os campos devem ser inicializados com um valor inicial (que tenha sentido no contexto onde está inserido).<br />
<br />
10. Cada nome de tabela deve começar com o prefixo da base de dados ($CFG->prefixo). Na maioria dos casos, isto é automaticamente feito. Também, no Postgres, o nome de cada índice tem de começar com o mesmo prefixo.<br />
<br />
11. Para garantir a compatibilidade entre bases de dados devem ser seguidas simples regras como o uso da palavra chave AS (apenas de for necessário alias em tabelas\colunas, claro):<br />
<br />
• Não usar a palavra chave AS para alias de tabelas.<br />
<br />
• Usar a palavra chave AS para alias de colunas.<br />
<br />
12. Nunca criar UNIQUE KEYS (restrições) sem nenhuma razão específica. Em alternativa, usar UNIQUE INDEXes. No futuro, se for decidido adicionar integridade referencial no Moodle e for necessário UNIQUE KEYS, serão usadas, mas por agora este facto não se irá verificar. De notar ainda que o editor XMLDB permite especificar restrições XMLDB-only UNIQUE e FOREIGN (o que é um ponto positivo, com o objectivo de ter o XML bem definido) mas apenas os INDEXes sublinhados serão gerados na base de dados.<br />
<br />
13. Essas UNIQUE KEYS XMLDB-only (ler ponto anterior) apenas podem ser definidas se esse campo\campos vão ser alvo de alguma (também XMLDB-only) FOREIGN KEY. Caso contrário, devem ser criadas como UNIQUE INDEXes.<br />
<br />
14. As tabelas associadas com um bloco devem seguir a seguinte convenção na atribuição dos seus nomes: <br />
$CFG->prefix + "block_" + nome_do_bloco+ o_restante. Por exemplo assumindo que $CFG->prefix é ‘mdl_’, todas as tabelas do bloco “rss_cliente” devem começar com ‘mdl_block_rss_client’ (sendo possível que se adicione mais palavras no final, por ex. ‘mdl_block_rss_client_outratabela’…). Esta regra será 100% forçada com o Moodle 2.0, dando entretanto tempo aos programadores. Para mais informações consultar Task 6786.<br />
15. Nunca fazer mudanças em porções de código ESTÁVEIS. Este facto poderá provocar sérios erros quando os utilizadores actualizarem a sua versão estável para outra.<br />
<br />
16. Quando existir referência a uma variável inteira em consultas SQL, não por o valor entre pelicas. Por exemplo, get_records_select('question', "category=$catid") está correcto. Já o exemplo get_records_select('question', "category='$catid'") está incorrecto. Este caso pode dar origem a que sejam ocultados erros em que o valor de $catid não esteja definido. (Esta thread explica este caso).<br />
<br />
[[en:Coding]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Ficheiro:Merging.png&diff=2518Ficheiro:Merging.png2008-05-17T17:39:26Z<p>Rubenback26: </p>
<hr />
<div></div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2517CVS para programadores2008-05-17T17:36:39Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
<br />
• moodle – o código fonte principal do Moodle<br />
<br />
• lang – todos os packs de idiomas<br />
<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
<br />
[[Imagem:Merging.png]]<br />
<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2516CVS para programadores2008-05-15T19:28:25Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
<br />
[[Imagem:Merging.png]]<br />
<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2515CVS para programadores2008-05-15T19:26:20Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
[[es:CVS para desarrolladores]]<br />
[[fr:CVS pour développeurs]]<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2514CVS para programadores2008-05-15T19:24:26Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2513CVS para programadores2008-05-15T19:23:18Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[:CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2512CVS para programadores2008-05-15T19:22:47Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2511CVS para programadores2008-05-15T19:21:55Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[pt:CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Ficheiro:branches.png&diff=2510Ficheiro:branches.png2008-05-15T19:20:49Z<p>Rubenback26: </p>
<hr />
<div></div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2509CVS para programadores2008-05-15T19:20:14Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
[[Imagem:branches.png]]<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=Ficheiro:Branches.png&diff=2508Ficheiro:Branches.png2008-05-15T19:19:28Z<p>Rubenback26: working with branches</p>
<hr />
<div>working with branches</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2507CVS para programadores2008-05-13T18:19:49Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
<br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2506CVS para programadores2008-05-13T17:56:30Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it. <br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2505CVS para programadores2008-05-13T17:36:07Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
<br />
<br />
== Mensagens commit CVS ==<br />
<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
<br />
== Trabalhando com ramos ==<br />
<br />
Este diagrama mostra como o módulo principal do Moodle se subdividiu e diferentes versões ao longo dos tempos. <br />
<br />
Para ver todas as etiquetas e ramos que estão disponíveis, use este comando em qualquer dos ficheiros antigos (tal como o índex.php a directoria raiz do moodle):<br />
<br />
cvs status –v índex.php<br />
<br />
Algumas directrizes de colocação de etiquetas: <br />
• O nome das etiquetas e dos ramos deve estar todo em letras maiúsculas. <br />
• As etiquetas e ramos devem ser SEMPRE aplicados ao módulo inteiro (todo o Moodle). Não etiquetar ficheiros ou directorias individuais.<br />
• Não é permitido renomear etiquetas devido aos utilizadores poderem ser induzidos em erro.<br />
<br />
<br />
'''Desenvolvimento do tronco (trunk)'''<br />
<br />
O tronco do CVS é a versão principal de desenvolvimento do Moodle. No CVS também conhecido como HEAD, o ramo por defeito (default branch). <br />
Os programadores do Moodle têm sempre como objectivo manter a plataforma o mais estável possível, mas com a constante introdução de pequenas porções de código, existe sempre a possibilidade da existência de pequenos erros e focos de instabilidade.<br />
Em qualquer momento podemos decidir que o produto tem funcionalidades necessárias para o lançamento de uma nova versão. Nesta altura, o troncoé marcado com uma etiqueta MOODLE_XX_BETA (com vista a poder voltar em qualquer momento a esse ponto) e um novo ramo é criado para essa versão com o nome de MOODLE_XX_STABLE.<br />
<br />
A Beta package is also released at this point - it's for testers who don't use CVS but want to test the latest features and report bugs. <br />
<br />
Neste momento é também publicado um pacote Beta – é para os utilizadores que não utilizam o CVS mas que querem comprovar as novas funcionalidades e ajudar na detecção de erros.<br />
<br />
'''Ramos estáveis para cada versão'''<br />
<br />
As soon as the stable branch MOODLE_XX_STABLE is created, development efforts will fork into two streams for a while. Some people may continue working on new features in the trunk for the next release, but most developers should be concentrating on using the current STABLE branch and fixing bugs that are found in it. <br />
Assim que o ramo estável MOODLE_XX_STABLE for criado, os esforços de desenvolvimento dividir-se-ão em dois caminhos por um algum tempo. Algumas pessoas podem continuar a trabalhar em características novas no tronco para a versão seguinte, mas a maioria dos programadores devem concentrar-se em usar o ramo ESTÁVEL actual e em reparar os erros que vão surgindo na mesma.<br />
É possível comutar uma cópia local do Moodle à versão ESTÁVEL usando o seguinte comando em Unix na directoria de raiz da plataforma:<br />
cvs update -dP -r MOODLE_XX_STABLE<br />
Depois disto, todos comandos descritos anteriormente serão aplicados ao ramo estável. Para voltar ao tronco, faz-se simplesmente:<br />
cvs update -dPA<br />
Em clientes Windows deverá existir um menu no qual se poderá fazer a escolher do ramo.<br />
Quando o novo ramo se apresentar com uma estabilidade aceitável, uma versão poderá ser declarada. Os pacotes são criados para a distribuição o ramo será etiquetado (por Martin Dougiamas) com uma etiqueta (tag) chamado: MOODLE_XXX.<br />
<br />
<br />
'''Adicionando correcções'''<br />
<br />
Todas as correcções de erros da versão ESTÁVEL devem ser adicionadas ao tronco de modo que se tornem disponíveis nas versões futuras de Moodle. Uma etiqueta (Tag) flutuante chamada MOODLE_XX_MERGED deverá ser mantida de modo a manter o caminho da última fusão. O procedimento para tal fusão é como segue (neste caso o CVS está a ser usado na linha de comando de Unix mas as etapas não diferem nos outros clientes de CVS):<br />
<br />
1. É altamente recomendado manter localmente uma cópia de segurança de cada ramo estável e da versão do tronco¬/versão principal de forma a ser fácil alternar entre elas. Ajuste-os todos como Web sites virtuais em sua máquina do desenvolvimento. Eu uso directórios como /moodle/18, /moodle/19 /moodle/dev etc.<br />
<br />
2. Faça a actualização para a última versão estável (eu usarei XX no exemplo mas poderia ser 18, 19 etc.) para os ficheiros relevantes, execute um cvs diff apenas para se certificar do que está a ser verificado. De notar que só é necessário fazer a actualização dos ficheiros/directorias onde se está a trabalhar, mas por vezes é aconselhável fazer uma actualização total com vista a fazer uma verificação final da funcionalidade utilizando a Web. <br />
cd /moodle/XX/user<br />
cvs update -dPA<br />
cvs diff -c file1.php file2.php<br />
<br />
3. Se tudo estiver correcto, fazer a . Verifique se a mensagem anexada à submissão contém (commit) o ID do tracker onde se encontra o erro corrigido (ex. MDL-1111) e uma boa descrição do raciocínio feito. Se não for especificada nenhuma mensagem na linha de comandos, aparecerá um modo de edição de modo a fazê-lo.<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field" file1.php file2.php<br />
<br />
4. Ir para a última versão do tronco e certificar-se que esta se encontra actualizada. <br />
cd /moodle/dev/user<br />
cvs update -dPA<br />
<br />
5. Fazer a junção de tudo na cópia local do tronco do ramo estável desde a ultima junção. Pode ser usada a sequência dos passos (4) e (5) Para adicionar as alterações noutros ramos estáveis ( para afectar as alterações a outras versões estáveis anteriores). <br />
cvs update -kk -j MOODLE_XX_MERGED -j MOODLE_XX_STABLE file1.php file2.php<br />
<br />
6. É aconselhável uma analise cuidada do log que resulta da actualização, para uma posterior reparação de todos os ficheiros que apresentarem conflitos. Depois , pode ajudar correr o comando diff para a certificação que o resultado é o esperado:<br />
cvs diff -c file1.php file2.php<br />
<br />
7. Verificar a cópia local da versão alterada e fazer a cópia para aversão CVS do tronco<br />
cvs commit -m "MDL-1234 Corrected a small typo in the user name field, merged from XX" file1.php file2.php<br />
<br />
8. Voltar á versão do ramo <br />
cd /moodle/XX/user<br />
<br />
9. Actualizar a etiqueta flutuante dos ficheiros modificados ( para que haja correspondência com MOODLE_XX_STABLE) para que o processo possa ser repetido da próxima vez.<br />
cvs tag -RF MOODLE_XX_MERGED file1.php file2.php<br />
<br />
Finalmente, os valores para $version em todos os ficheiros version.php Moodle dentro do ramo estável se possível não devem ser actualizados (excepto o último dígito se absolutamente necessário). A razão é que alguém que faça a actualização de uma versão muito estável à versão muito estável seguinte poderia não beneficiar dos melhoramentos da base de dados que aconteceram no tronco.<br />
<br />
'''Características dos ramos para grandes alterações'''<br />
<br />
Ocasionalmente, pode haver uma funcionalidade muito grande que necessite ser analizada para que muitos utilizadores possam trabalhar nela, mas sendo demasiado instável não é aconselhável incluí-la no desenvolvimento tronco principal.<br />
Nestes casos pode ser criado um ramo de curto prazo em que irá ser trabalhada essa funcionalidade, para depois a mesma ser adicionada ao tronco da versão principal o mais brevemente possível. Um exemplo deste tipo de ramo chamado MOODLE_17_WIDGET pode ser visto no diagrama acima.<br />
Se for necessário utilizar este método (widget), siga os seguintes passos:<br />
<br />
1. Discutir a situação com outros programadores e certificar se esta opção será mesmo necessária.<br />
<br />
2. Fazer uma etiqueta no tronco (de todo o moodle) com o nome de MOODLE_XX_WIDGET_PRE<br />
cvs tag -R MOODLE_XX_WIDGET_PRE<br />
<br />
3. Criar um ramo próprio chamado MOODLE_XX_WIDGET<br />
<br />
cvs tag -Rb MOODLE_XX_WIDGET<br />
<br />
<br />
4. Trabalhar esse ramo até que seja atingido um nível aceitável de estabilidade. Fazer a submissão (commit).<br />
cvs commit<br />
<br />
<br />
5. Quando o trabalho estiver finalizado, adicionar o ramo inteiro ao tronco, reparar conflitos, submeter para o tronco e depois abandonar o ramo.<br />
<br />
cvs update -dPA<br />
cvs update -kk -j MOODLE_XX_WIDGET<br />
cvs commit<br />
<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2504CVS para programadores2008-05-13T16:17:20Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. <br />
Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2503CVS para programadores2008-05-13T16:15:44Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2502CVS para programadores2008-05-13T16:14:50Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
.2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
.1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
.2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
.3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
.4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2501CVS para programadores2008-05-13T16:02:15Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2500CVS para programadores2008-05-13T15:58:36Z<p>Rubenback26: </p>
<hr />
<div>== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2499CVS para programadores2008-05-13T15:56:27Z<p>Rubenback26: </p>
<hr />
<div><br />
== Desenvolvimento: '''CVS para programadores''' ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2498CVS para programadores2008-05-13T15:55:50Z<p>Rubenback26: </p>
<hr />
<div><br />
<br />
== == Desenvolvimento: '''CVS para programadores''' == ==<br />
<br />
<br />
<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
<br />
== Entrar no projecto como programador ==<br />
<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
<br />
== Módulos CVS ==<br />
<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
<br />
<br />
== Comandos CVS básicos ==<br />
<br />
<br />
'''CVS em Unix'''<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ...<br />
<br />
<br />
'''CVS no Mac OSX'''<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com).<br />
<br />
<br />
'''CVS em Windows'''<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26https://docs.moodle.org/archive/pt/index.php?title=CVS_para_programadores&diff=2497CVS para programadores2008-05-13T15:50:54Z<p>Rubenback26: </p>
<hr />
<div>Desenvolvimento: CVS para programadores<br />
<br />
CVS são as iniciais de Concurrent Versioning System, uma forma de trabalho habitualmente utilizada para grandes projectos de software. No CVS estão integradas todas as versões de todos os ficheiros para que nada seja perdido e a sua utilização pelos vários utilizadores seja registada. Este sistema permite também a combinação do código criado por duas ou mais pessoas que trabalhem simultaneamente sobre o mesmo ficheiro. Todo o código e respectivas versões são armazenados num servidor central (no caso do Moodle, em cvs.moodle.org). Para mais informações sobre CVS, poderá consultar o livro on-line "Open Source Development with CVS"..<br />
<br />
Entrar no projecto como programador<br />
Se obteve permissões de escrita no CVS para ajudar a desenvolver e manter o Moodle! Bem-vindo a bordo!<br />
Para obter estas permissões para escrever ou editar no Moodle's CVS archive, primeiro deverá ter uma conta no servidor. Só programadores de confiança conseguem estas contas. Para conseguir o acesso, deverá procurar o link "Apply for CVS Access" na página CVS do Moodle.org (http://moodle.org/cvs), comunicar quais os módulos aos quais deseja ter acesso (por exemplo: modulo de idioma) e porquê. A resposta será dada em menos de um dia.<br />
Concluída esta fase, já deverá possuir todas as permissões de que necessita, necessitando apenas de configurar a sua máquina e descarregar o código fonte corrente, podendo logo de seguida começar a trabalhar nele. <br />
Para os exemplos que veremos mais à frente vamos assumir que o nosso nome de utilizador é myusername a nossa password é mypassword.<br />
<br />
Módulos CVS<br />
Dentro do CVS, a palavra “módulo” refere-se a conjuntos separados de código. Nos arquivos do Moodle existem os seguintes módulos:<br />
• moodle – o código fonte principal do Moodle<br />
• lang – todos os packs de idiomas<br />
• contrib – contribuições de utilizadores e todo o tipo de código em desenvolvimento.<br />
• mysql – um phpMyAdmin para trabalhar com a base de dados do Moodle.<br />
• windows-cron - um pequeno pacote que possibilita o funcionamento do ?cron? nos sistemas Windows.<br />
• docs – diversas contribuições de utilizadores para documentação.<br />
<br />
A maioria das pessoas está a trabalhar nas funcionalidades existentes no módulo moodle, mas muitas estão também contribuindo com novas ideias para o módulo contrib. Uma vez alcançado um certo nível de “maturidade” no código da área contrib, este pode ser migrado para a área principal da área moodle. <br />
<br />
Comandos CVS básicos <br />
CVS em Unix<br />
O CVS do Moodle utilize ssh como camada de transporte para segurança, pelo que deverá ter a variável de ambiente CVS_RSH na sua Shell Unix. E aconselhável por estes comandos nos seus arquivos .bashrc ou .chrc para não ter de os digitar repetidamente:<br />
setenv CVS_RSH ssh (para csh, tcsh etc)<br />
export CVS_RSH=ssh (para sh, bash etc)<br />
Seguidamente, poderá obter a última versão do Moodle utilizando este comando (todo na mesma linha).<br />
NOTA: Não tente correr este primeiro comando CVS sobre uma instalação do Moodle já existente: Inicie novamente com uma nova directoria:<br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co moodle<br />
Para outros módulos CVS, os comandos são semelhantes: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co contrib<br />
Se desejar obter simplesmente um plugin (no exemplo é o bloco “attendance”) existente em contrib dentro da directoria actual, pode usar: <br />
cvs -z3 -d:ext:myusername@cvs.moodle.org:/cvsroot/moodle co -d attendance contrib/plugins/blocks/attendance<br />
Cada vez que se executa um comando é pedida a password, poderá no entanto configurar as chaves autorizadas de forma a contornar esta situação.<br />
Deverá agora ter uma nova directoria ‘moodle’, podendo alterar o seu nome ou localização. Entre em:<br />
cd moodle<br />
Todos os ficheiros do Moodle devem estar nesta localização, possibilitando localmente (na cópia instalada) a alteração dos mesmos. Para comparar os seus ficheiros com os da cópia principal do CVS no servidor poderá utilizar os comandos cvs diff, por exemplo:<br />
cvs diff -c config-dist.php<br />
cvs diff -c lang<br />
Para obter as ultimas actualizações a partir do servidor:<br />
cvs update -dP<br />
Para copiar os seus novos ficheiros de volta para o servidor necessitará de algo como:<br />
cd lang/ca<br />
cvs commit<br />
Ser-lhe-á pedido que adicione alguns comentários (dependendo do seu editor de texto predefinido). Deverá escrever comentários descritivos e com significado. Depois disto as suas alterações serão enviadas para o servidor CVS e guardadas no respectivo repositório.<br />
Para poupar algum tempo poderá colocar argumentos predefinidos dentro de um ficheiro chamado .cvsrc na sua directoria principal. Por exemplo, o meu contém: <br />
diff -c<br />
update -dP<br />
Poderá utilizar o 'cvs help' para mais informações ... <br />
CVS no Mac OSX<br />
Poderá seguir as mesmas instruções descritas anteriormente para Unix numa janela terminal. No entanto o comando cvs não está instalado por defeito no OSX. Deverá instalar previamente as ferramnetas XCode. Deverá encontar as mesmas no seu disco de instalação original. Caso contrário poderá descarrega-las a partir do Web site da Apple para o desenvolvimento (http://devoloper.apple.com). <br />
CVS em Windows<br />
Primeiro, deverá descarregar uma cópia actual do Moodle usando a sua conta de programador.<br />
1. Descarrega TortoiseCVS a partir de tortoisecvs.org, instale e reinicie.<br />
2. Procure ou crie uma pasta onde o Moodle possa ser descarregado.<br />
3. Clique com o botão direito do rato na pasta e escolha “CVS Checkout”. Deverá surgir uma caixa de diálogo.<br />
4. Copie este texto para o campo CVSROOT (utilizando o seu próprio username!):<br />
:ext:myusername@cvs.moodle.org:/cvsroot/moodle<br />
5. No campo “Module”, digite “moodle” para obter a ultima versão do moodle, “contrib” para obter a directoria de contribuições ou “mysql” para obter o módulo MySQL Admin.<br />
6. Clique em “OK” e tudo será descarregado.<br />
Uma caixa de diálogo deverá mostrar todos os ficheiros que estão a ser descarregados, depois disto já deverá ter uma cópia completa do Moodle instalada. Poderá posteriormente obter actualizações a partir do servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Update”.<br />
2. Examine atentamente os registos e tome nota dos conflitos que podem ocorrer entre as alterações ao código que efectuou na sua cópia e as novas versões obtidas. Estes ficheiros terão de ser editados manualmente de forma a resolver os conflitos. <br />
Depois de modificar os ficheiros (os seus ícones mudarão de verde para vermelho), poderá enviar as alterações de volta ao servidor CVS:<br />
1. Clique com o botão direito do rato na sua pasta Moodle (ou em qualquer dos seus ficheiros) e escolha “CVS Commit…”.<br />
2. Na caixa de diálogo, digite uma descrição clara das alterações que estão a ser submetidas. Incluindo sempre o nome de qualquer edição do Tracker do Moodle relacionado com o que está a ser corrigido (MDL-XXXX).<br />
3. Clique em “OK”. As suas alterações serão enviadas para o servidor.<br />
4. Se criar uma pasta, deverá ter algum cuidado ao usar a opção “CVS add” pois irá acrescentar a pasta ao CVS sem requerer verificação/confirmação (commit) da mesma. Uma vez adicionada, a pasta não pode ser removida do CVS mesmo que esteja vazia.<br />
NOTA: Deverá ter em atenção que (à data de edição deste texto em Abril de 2008) o TartoiseCVS 1.10.6 poderá não funcionar plenamente com o Windows Vista. Poderá reportar bugs e encontrar mais informação no site TortoiseCVS ou no Google “TortoiseCVS vista”. <br />
Mensagens commit CVS<br />
Por cada alteração submetida no CVS, deverá receber uma mensagem de confirmação/verificação (denominada commit), contendo o ID da edição (por exemplo, MDL-12345) e da breve descrição do problema nela corrigido. <br />
Se julgar que a breve descrição é insuficiente, poderá adicionar mais informação no Tracker do Moodle.org ou no Moodle Docs (https://docs.moodle.org).<br />
<br />
[[en:CVS_for_Developers]] [[CVS_para_programadores]]</div>Rubenback26