Vou fazer desta resposta um artigo de blog, uma vez que foi um pouco fora do tópico GRIN. Em http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ no capítulo 6, expliquei o SVN no eclipse, mas você provavelmente está procurando algo mais.
A história que fiz aqui foi sobre o seu comentário
"Então, por enquanto, uso os recursos de integração de VCS nos IDEs (NetBeans, PHPStorm). O que geralmente me deixa confuso quanto a detalhes e maneiras de fazer as coisas corretamente." e "Algo que se concentra nos conceitos e no fluxo de trabalho, em vez de digitar linhas arcanas no console".
Ouvi dizer que mais uma vez eu queria explicar o SVN em um contexto mais amplo, por exemplo, descrevendo "linguagens de programação" primeiro e depois explicando o PHP faz com que você entenda melhor o PHP e, neste caso, o Gerenciamento de configuração primeiro e depois a solução SVN nele.
Vou apenas digitar algo aqui e, se estiver fora do tópico ou não for necessário, vou excluí-lo:
------------ 8 <----------------
Se você instalar o Eclipse PDP, escrevi isso: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Se você rolar para o número 6, explico brevemente como instalar o subclipse collabnet no Eclipse (basicamente apenas aponte para o servidor, selecione tudo e instale)
No Eclipse, com qualquer ferramenta de gerenciamento de versão, os comandos para gerenciamento de versão estão sempre sob o botão direito do mouse, clique em "EQUIPE". Como você pode alternar entre projetos, pode ter suporte para várias ferramentas de gerenciamento de versão e a maioria dos comandos é familiar sobre as ferramentas via GUI.
Plugins
Como você sabe: Para um novo projeto de plug-in do WordPress, você obtém um local svn do WordPress.org (na sua caixa de correio), eles usam o Trunk para o seu código mais recente e copia "tags" para lançamentos estáveis. (Padrão CM muito básico). É isso que você vê à primeira vista.
Portanto, seu projeto será vinculado ao TRUNK. e você pode simplesmente se comprometer com isso. Este é o local em que você trabalha (mas não é de onde você o libera) (a menos que você especifique 'trunk' no readme.txt como local para o seu código final).
Além disso, você pode incluir o WordPress / wp-includes e / wp-admin em seu projeto Eclipse como bibliotecas, para que você possa procurar funções e ver funções obsoletas. Eles não são graváveis e, portanto, não se enquadram no gerenciamento de versões (!). Isso é do lado do cliente, portanto não os "externos" que realmente estão vinculados no projeto de gerenciamento de versões.
Assim que você tiver uma versão estável, selecione o material e clique com o botão direito do mouse em "equipe" e "criar tag / filial", isso abrirá o local svn do WordPress e você poderá selecionar o diretório de tags e digitar um novo número e sua nova versão estará ativa (que talvez seja útil para alguém que está lendo isso). Observe que você não deve selecionar a raiz do seu projeto, mas tudo o mais, ou criará essa raiz também em suas tags / 2.3.4, que não é o que você deseja, e que tudo que quer que esteja sob a raiz esteja no diretório / tag.
Veja a postagem para algumas capturas de tela.
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress próprio Colaborador
Se você é um colaborador, pode usar o mesmo que acima, mas criar "patches" a partir das alterações feitas. "Patches" é um conceito no mundo do CM, por exemplo, o subversion fornece este RTC ou jazz. Com o botão direito do mouse, clique em "Aplicar patch", você pode aplicar um patch se você tiver um patch que ainda não foi aplicado ao tronco do WordPress.
Algumas pessoas também se comprometem diretamente com o tronco.
WordPress em si "Ler"
Basta criar um projeto 'WordPress' que contenha uma verificação da versão / LATEST no tronco (do código de subversão), novamente, através do team> checkout.
Pessoalmente, não faço isso, apenas uso uma exportação do código mais recente (com força) para obter um diretório com a versão mais recente do WordPress (para que não se enquadre em nenhum gerenciamento de versão)
Em geral
Como você tem alguma experiência com o VCS e com perguntas sobre o SVN: Basicamente, todas as ferramentas de versão são sobre o conceito de nomear coisas. Ou melhor, ter o melhor espaço para nome. Você pode mapear a maioria dos comandos do CVS, Git, RTC, ClearCase, SourceSafe etc ... para o conceito em torno desse espaço para nome. Como você tem alguma / pouca experiência com outras ferramentas, um pouco mais amplo:
As pessoas novas geralmente se veem cegas em determinados comandos ou em uma parte específica da funcionalidade, mas é a principal opção fornecer todos os elementos necessários em um espaço para nome.
Portanto, como essa é basicamente a funcionalidade principal dessas ferramentas, o termo "gerenciamento de versão" está errado. Na verdade, é um gerenciador de espaço de nome.
Então se você tem
/ projeto A / departamento B / Equipe C / Membro D / Fluxo E / Componente F / Elemento G / Filial H / Filial I / Versão J
Você pode criar um nome exclusivo para cada "coisa". A descrição acima é uma implementação de um espaço para nome que você precisa para uma determinada finalidade usando uma das ferramentas de espaço para nome.
Quase todos os conceitos deste mundo podem ser mapeados para isso, de modo que a maneira como você PODE suportar seu espaço de nome / taxonomia personalizados depende dos recursos de sua ferramenta. Então ... depende realmente dos conceitos e escolhas que os designers das centenas de ferramentas diferentes fizeram.
Em uma boa ferramenta, você pode clicar e ver esta taxonomia completa em uma árvore ou aumentar o zoom em uma árvore.
Esse é o núcleo: uma ferramenta que pode ajudá-lo a gerenciar a complexidade (consulte a complexidade na wikipedia: http://en.wikipedia.org/wiki/Complexity ), fornecendo boas ferramentas para gerenciar sua taxonomia personalizada. A pessoa que cria a taxonomia e pensa em como configurá-lo é o gerente de configuração; ele escreve um plano chamado plano de gerenciamento de configuração, pensando primeiro nisso.
Imagine alguém pedindo para você criar um conjunto de taxonomias personalizadas no WordPress que representam TODOS os objetos em sua empresa, incluindo a capacidade de tirar o estado disso como era a qualquer momento. Você pode fazer muitas opções de design e todos produzirão algo mais com base em algumas opções. Alguns conterão mais recursos, outros são mais simples e os mais complexos tomaram decisões diferentes. Isso é "essas ferramentas". Portanto, nunca entendo as discussões no nível da ferramenta sobre gerenciamento de versões, porque isso é completamente estranho.
Atualmente, no PHP, você pode criar namespaces, fazer uma hierarquia com diretórios, aplicar convenções de nomenclatura a objetos e dentro desses métodos. Se você pegar um arquivo que você colocou em uma hierarquia, dê um passo adiante. Você adiciona um / atrás dele e coloca um número de versão atrás dele. Isso nem é suficiente, porque você deseja que a equipe A trabalhe na versão 4 do arquivo e a equipe B trabalhe nessa versão. Então você adiciona outro / e adiciona o ID do ramo. É assim que você cria o espaço para nome. Dependendo da ferramenta, você pode ficar tão louco quanto você gostaria.
Mas significa: se alguém lhe perguntar "onde está o documento Z", você não poderá dar a resposta. Porque em um sistema de gerenciamento de versões "documento Z" não existe. E mesmo quando ele me diz "documento Z versão 5", você não pode entregá-lo, pois ele pode significar "documento Z versão 5" da ramificação da equipe 1 ou "documento Z versão 5" da ramificação da equipe 2. É tudo sobre nomeação. "documento Z versão 5" é simplesmente uma abordagem de nomeação incorreta no espaço para nome definido.
No Subversion, você só pode fazer isso de forma limitada, o que facilita a compreensão. Alguns conceitos correspondem a isso:
"versão"
Uma versão é uma revisão de um determinado elemento. Por exemplo, wp-config.php versão 5. Em uma ferramenta como o ClearCase, você também pode ver versões individuais de elementos e "confirmar" arquivos individuais (mas também realizar confirmações atômicas ou alterar o conjunto ou o que for).
Nas versões de manipulação do Subversion é mais limitado:
- um conjunto de alterações feitas localmente de uma só vez, você " confirma ", o que significa que esse conjunto completo de "alterações" é confirmado atomicamente e toda a base recebe um novo número de versão. Este é o número da versão que você vê no site de subversão do WordPress.
- portanto, não é possível fazer mais alterações localmente em um arquivo e tratá-las todas como novas versões singulares, como no clearcase. todas as alterações feitas localmente nesse arquivo ou em qualquer outro são enviadas de uma só vez e recebem esse "novo nome exclusivo".
- se você não tiver acesso ao repositório (direitos), poderá fazer um conjunto de alterações e salvá-las em um "patch". Em seguida, você pode enviar esse patch para alguém como um gerente de integração ou mesmo um gerente de construção que o aplique ao repositório. Ferramentas como, por exemplo, o RTC também suportam "patches". Portanto, uma pessoa cria um patch e outra aplica o patch. Você deve considerar isso realmente, pois a palavra significa "um patch" para que não seja o caso de uso padrão do desenvolvimento de código.
- em vez de / branch N / hello.doc / versão 25, também existem rótulos como / branch N / hello.doc / LATEST ou / HEAD. Em alguns sistemas de gerenciamento de versão, você pode aplicar rótulos complexos e, em seguida, gravar scripts trabalhando nesses rótulos.
trabalhando em uma versão
No Subversion, o caso de uso padrão é que você simplesmente baixa todas as coisas para o seu disco rígido a partir de um checkout de repositório , trabalha nas coisas e depois confirma e depois enfrenta todas as mudanças que outras pessoas fizeram depois que você resolve conflitos. Esses conceitos que você vê na GUI. SE você quer evitar que outra pessoa também editar o seu ex hello.doc então você BLOQUEAR isso significa: ninguém mais deve ser capaz de mudá-lo.
REALMENTE não gosto dessa ideia :( IMHO, que é uma prática muito ruim. Para comparação e entendimento: no ClearCase, um checkout é mais ou menos comparável a um bloqueio e um checkin é um commit (no subversion checkin é um alias para commit) . este é o caso de uso padrão no ClearCase, onde ele também suporta seqüestros que é o mesmo que uma subversão check-out , mas depois nos arquivos selecionados IMHO este é muito mais limpo Além disso, mesmo quando você fazer o.. check-out no ClearCase lhe dá 3 opções: outro as pessoas podem não trabalhar nele (por exemplo, com o word docs), outras pessoas podem trabalhar nele, se realmente necessário, e "todos podem trabalhar nele" (por exemplo, com arquivos de código-fonte) Então ... é isso que significa fazer checkout, bloquear e confirmar em SVN.
componentes e linha de base
Em ferramentas como RTC e ClearCase, você pode agrupar elementos em componentes. Poderoso, pois esses componentes fazem parte do espaço para nome e obtêm versões próprias, baselando-os. Então, por exemplo, o componente "WordPress" obtém a versão 4.53 da linha de base. Essas linhas de base são objetos em si mesmas que também podem obter metadados como "em teste". No entanto, o SVN não possui QUALQUER isso. Assim... :
Tag
No SVN (e assim por diante no site WordPress), você vê diretórios com números em um diretório geral chamado 'tags'. Uma ideia de solução alternativa. Você simplesmente pega um determinado repositório e o despeja (com base em arquivo) em um diretório tags / 3.2.4. É isso aí. Ele não tem relação no namespace de gerenciamento de versões, etc ... apenas um diretório simples ... SIGH ..... IMHO impossível fazer qualquer gerenciamento de configuração com esse tipo de ferramenta. Portanto, não é um objeto de metadados no qual você pode criar scripts e atribuir propriedades e fazer as coisas mais loucas, não ... é apenas um diretório ............. No RTC para comparação, você pode criar um ' instantâneo 'de uma determinada linha de base para também suportar esse caso de uso. No ClearCase UCM, você cria uma nova ramificação / fluxo de uma determinada linha de base e, em seguida, 'visualiza'.
galhos
Isso não é usado no ambiente WordPress, tanto quanto eu sei, mas talvez eu esteja errado e há equipes fazendo isso nos lançamentos do WordPress para apoiar as alterações de porta em versões mais antigas. Então eu não sei, talvez alguém saiba.
Isso é usado para a árvore do espaço para nome. Para ter duas equipes trabalhando no mesmo código, você pode dizer "em inglês" \ team 1 \ hello.doc e \ team 2 \ hello.doc. As duas equipes continuam trabalhando e, depois de um tempo, você tem \ team 1 \ hello.doc \ versão 51 e \ team 2 \ hello.doc \ versão 23. (portanto, a equipe 1 fez 51 versões e a equipe 2 fez 23 versões). Agora você tem a possibilidade de mesclar da equipe de ramificação 1 para a equipe de ramificação 2 e fará a fusão na equipe 2, mas no final a equipe 2 terá todas as alterações da equipe 1 (versão 24) e as ramificações individuais ainda mostrarão o trabalho de cada uma. deles.
No RTC e ClearCase, isso não é usado, mas um objeto mais avançado chamado "fluxos" (para comparação). De uma perspectiva baixa, você pode considerá-los da mesma forma, mas ... quando você está na vida real, seus galhos conterão MUITO material. Então, no mundo real, você teria que fazer anotações, notas de versão, documentação etc. ... Para aprimorar isso, um fluxo contém não apenas o "código", mas também as "alterações", para que você saiba que o RFC23 era sobre a versão 34,32 e 56 e você pode liberá-los separadamente.
IMHO se você deseja configurar as coisas corretamente, então você dá a cada pessoa um ou mais fluxos / filiais pessoais. Para que eles possam fazer check-in / commit e check-out a partir daí, isso não incomoda ninguém. somente quando alguém está pronto, eles "entregam" suas coisas para, por exemplo, o fluxo da equipe e o fluxo da equipe entrega para o fluxo de integração etc ... No WP, possivelmente os lançamentos são ramificações, mas para pessoas comuns: todos trabalham na mesma ramificação. Uma desvantagem, pois os "testes de projetos" estão em c: \ temp e não estão sob gerenciamento de versões e você não pode ter um grupo de pessoas trabalhando temporariamente no recurso X que será necessário apenas em 5 versões.
o mundo ideal e as compensações
se você tiver \ team1 \ hello.doc e alguém copiar em \ team2 \ TAMBÉM hello.doc que este é BAaaaaad. Desde agora, temos 2 elementos com IDs diferentes, nos quais o usuário pensa que eles são iguais, mas o sistema os trata como não iguais. Isso é chamado de 'gêmeos maus' e você nunca deve fazer isso nesse tipo de ambiente. Sempre mesclar ou base de galhos. Se você entende os gêmeos maus, entende os ramos (por que isso é ruim: porque, em uma mesclagem, eles serão tratados como duas entidades diferentes, enquanto você deseja que eles sejam tratados da mesma forma) (ou comportamento diferente em diferentes sistemas). Se um novo usuário estraga tudo, é isso mesmo. 'Eu acabei de excluir hello.doc e copiados-lo de volta em' argh
ALTERAR
O SVN não oferece suporte a este MAS, mas existem ferramentas que você pode integrar a ele para oferecer suporte a algum tipo de ALM / gerenciamento de alterações integrado. Em ferramentas como a variante ClearCase-UCM ou RTC, você não pode alterar 1 letra sem que haja um defeito, RFC, ticket, etc ... No SVN quando você confirmavocê pode digitar uma descrição para seu commit atômico. Significado: você deve tentar fazer alterações em partes "localizáveis" em outras palavras: faça um commit atômico por defeito / alteração para ter um comportamento desse tipo. (mas é claro que em nenhum outro momento todos eles estão vinculados em uma árvore de nomes, como no banco de dados ClearCase) (para que você possa automatizar as notas de versão ou ajudar o pobre rapaz sendo gerente de implementação a obter vários novos conjuntos de códigos, alterações, liberações e tentativas misturá-lo com nenhuma ferramenta real para lhe dar uma ideia do que realmente é).
Como o SVN não suporta o WordPress de gerenciamento de alterações configurado para usar o TRAC: http://core.trac.wordpress.org/ como você sabe, porque mora lá :)
Sinto que o TRAC está lá porque falta uma ferramenta real, como o ClearCase ou o RTC, com alterações integradas como objetos (sim, contra a qual você programa). Portanto, você tem uma ferramenta na qual discute e envia um "tipo de" alteração definida (enquanto esse conceito também está ausente). Portanto, esses são os "patches", apenas um monte de arquivos sem nenhum dos metadados que você esperaria em um bom sistema (então, agora estou no estado Grumpy). O número de TRAC é importante, pois esse é o ID geral na árvore de nomenclatura vinculada a algumas alterações.
Entregando Alterações
Isso é algo para escrever em um artigo de blog separado. Resumindo: no mundo ideal, você deseja selecionar as alterações que deseja 'entregar' (ou outro conceito) e depois não se preocupar com arquivos, diretórios (versões do). Você apenas "entrega RFC 3 e 5". É assim que o ClearCase UCM ou RTC funciona. No SVN / base clearcase, você 'submete' um monte de arquivos nos quais esperamos que você tenha tomado a decisão certa. Essa é uma grande diferença e importante. (é por isso que o SVN é usado principalmente em conjunto, integrado com, por exemplo, jira / clearquest / etc ... para atingir esse comportamento). Patching .... não está entregando, é mais de um fluxo para outro como um 'patch' uhm.
Externals
Em outras ferramentas, isso de forma diferente no SVN é mais simples: se você possui código de uma parte que não é sua, pode tratá-lo como versão externa gerenciada e ... voltando ao conceito principal: você quer dizer que A parte não se enquadra na responsabilidade do espaço de nome, pois se trata de nomeação. MAS, embora seja externo, é de sua responsabilidade.
Na GUI, não há fluxo de trabalho no "mouse direito" normal, mas é definido na estrutura do projeto. Portanto, isso faz parte da sua definição.
Este conceito, se usado, é definido no IEEE CMP conforme necessário para definir (Veja abaixo)
Integração e Fusões
Como disse. O paradigma por trás do SVN é obter coisas localmente, fazer o seu trabalho e, em seguida, confirmar e, em seguida, ter o ***. Na GUI, você obtém exatamente as mesmas ferramentas que a maioria das outras. Aqui você realmente deve entender a fusão de três vias, a fusão de duas vias e a diferença entre conflitos que podem ser resolvidos automaticamente e conflitos que não podem ser resolvidos automaticamente. Este último se divide em duas classes: aqueles em que a ferramenta pode propor qual seria o bom resultado final e aqueles em que ela não sabe qual seria o fim. Você perguntou sobre a GUI, mas na linha de comando você obtém arquivos de informações sobre o que deve corrigir / mesclar antes de confirmar.
Muito mais para um artigo de blog. (por exemplo, desenvolvimento de código aberto versus desenvolvimento corporativo e construa meisters e gerentes de integração, já que você realmente precisa fazer escolhas diferentes aqui).
Por último, mas não menos importante, o CMP
O que você pede é um Plano de Gerenciamento de Configuração para WordPress. Este é um documento IEEE. Significado: qualquer que seja o milhão de planos de gerenciamento de configuração que você encontra no Google, todos são válidos no IEEE especificado (várias versões) do CMP.
Assim como as RFCs (por exemplo, HTTP), existe o CMP IEEE.
Este plano contém seções definidas como "como tratar os aspectos externos" e "como é o espaço para nome, como recuperamos itens e como reproduzimos itens", funções, responsabilidades etc.
Nesse CMP, você pode criar instruções de trabalho. Qualquer pessoa que queira saber quais são as regras pode ler o CMP.
Em um contexto de código aberto, frequentemente a função 'gerenciador de configuração' está ausente. Então você também perde o Plano de Gerenciamento de Configuração.
Diferente de uma RFC pública (por exemplo, URI ou HTTP) Você precisa pagar pelo documento padrão IEEE, mas ... se você pesquisar no Google, encontrará aqui e ali.
Delivery Street
Em uma rua de entrega, você teria uma equipe pensando em novas idéias de negócios. Você tem um departamento de manutenção recebendo um zilhão de erros de produção em seu sistema. Você teria várias equipes trabalhando no mesmo código. e em cada substreet você teria uma equipe de requisitos definindo requisitos. Uma equipe de arquitetura dividida em uma equipe funcional e uma equipe operacional (os casos de uso vão para a equipe funcional e os não funcionais para a equipe operacional). Muitas vezes, você tem diferentes lançamentos paralelos ao vivo em um ambiente de teste de unidade, ambientes de aceitação, ambientes de carga e teste de estresse, ambientes de teste funcional, ambientes de teste de pré-produção e ambiente (s) de produção.
Em todas elas existem versões que são rastreadas uma para a outra.
uma versão em um ambiente de teste específico está vinculada a um conjunto de versões vinculadas a uma RFC específica e esta está vinculada a versões específicas de um requisito. O requisito é então vinculado a uma versão específica de um conjunto de testes. TODOS se enquadram no gerenciamento de versões.
No WP com SVN / TRAC, ainda não encontrei o banco de dados de requisitos e o banco de dados de versão dos requisitos. (para que você possa fazer análises de impacto e ver qual código é alterado se alterar um requisito) (e que, em uma nova versão, você pode imprimir quais requisitos foram alterados). Vi itens individuais no TRAC, nos quais são feitos links para outros itens individuais no TRAC nos comentários. Também não vi rastreabilidade entre os itens do TRAC e o código, exceto nos comentários. Isso significa que as pessoas estão fazendo muito em suas cabeças e isso depende muito de uma comunidade ativa ou de desenvolvedores principais, pois eles têm muito disso em seu cérebro.
Mas isso está indo muito longe do sorriso do tópico
OSLC para ALM
Apenas mais uma observação para esta história: não seria bom se houvesse um pacote de padrões para todas essas ferramentas de gerenciamento de ciclo de vida de aplicativos (ALM)? Alguém pensou nisso e agora existem padrões para que todos os conceitos sejam colocados em um nível de abstração mais alto e depois implementados nas ferramentas. Google: OSLC para ALM. (para que todas as ferramentas possam conversar entre si e com o usuário: para que você as entenda todas, entendendo a camada de abstração).
CALMA
Um passo adiante, se você tiver tempo: o mundo está agora indo para o C / ALM, uma próxima geração de produtos onde os processos e as ferramentas são uma coisa integrada, para que você não precise mais se perguntar qual é o processo. O primeiro produto desta geração é o RTC. Portanto, se você entende bem o SVN ou entende ClearCase ou Jira ou Trac ou ANT ou Agile ou RUP ou iRUP ou qualquer outro processo, gerenciamento de versões, gerenciamento de alterações, gerenciamento de build, precisará de tudo isso para entender o RTC, porque tudo isso é combinado em uma coisa, porque todos eles se unem e isso por si só faz interface com o OSLC, para que qualquer uma dessas ferramentas mais antigas possa "conectar-se".
Mas agora estou realmente fora de tópico.