Farò di questa risposta un articolo di blog dal momento che è diventato leggermente fuori tema GRIN. Su http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ nel capitolo 6 Ho fatto alcune spiegazioni per SVN in eclipse ma probabilmente stai cercando qualcos'altro.
La storia che ho fatto qui parlava del tuo commento
"Quindi per ora lo alzo con le funzionalità di integrazione VCS negli IDE (NetBeans, PHPStorm). Ciò mi lascia spesso confuso su specifiche e modi di fare le cose correttamente." e "Qualcosa che si concentra su concetti e flusso di lavoro, piuttosto che digitare linee arcane in console."
Ho sentito che ancora una volta ho voluto spiegare SVN in un contesto più ampio, ad esempio descrivendo prima i "linguaggi di programmazione" e poi spiegando PHP che ti fa capire meglio PHP e in questo caso prima la gestione della configurazione e poi la soluzione SVN in esso.
Scriverò semplicemente qualcosa qui e se è fuori tema o non necessario, lo cancellerò:
------------ 8 <----------------
Se installi Eclipse PDP, ho scritto questo: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Se scorri verso il basso fino al numero 6, ti spiego brevemente come installare la subclipse di collabnet in Eclipse (in pratica basta selezionare il server, selezionare tutto e installare)
In Eclipse con qualunque strumento di gestione delle versioni, i comandi per la gestione delle versioni sono sempre sotto il tasto destro del mouse, fare clic su "TEAM". Poiché è possibile passare da un progetto all'altro, è possibile disporre del supporto per più strumenti di gestione delle versioni e la maggior parte dei comandi ha familiarità con gli strumenti tramite la GUI.
plugin
Come sai: per un nuovo progetto di plugin per WordPress ottieni una posizione svn da WordPress.org (nella tua casella di posta), usano il Trunk per il tuo ultimo codice e le copie dei "tag" per le versioni stabili. (Modello CM di base MOLTO semplice). Questo è ciò che vedi a prima vista.
Quindi il tuo progetto sarà collegato a TRUNK. e puoi semplicemente impegnarti a questo. Questo è il posto in cui lavori (ma non da dove ti rilasci) (a meno che non specifichi 'trunk' in readme.txt come posizione per il tuo codice finale).
Inoltre puoi includere WordPress / wp-Includes e / wp-admin nel tuo progetto Eclipse come librerie in modo da poter cercare funzioni e vedere funzioni deprecate. Questi non sono scrivibili e quindi non rientrano nella gestione delle versioni (!). Questo è dal lato client, quindi non gli "esterni" che in realtà si collegano nel progetto di gestione delle versioni.
Non appena hai una versione stabile, seleziona il materiale e fai clic con il pulsante destro del mouse su "team" e "crea tag / ramo", si apre la posizione svn di WordPress e puoi selezionare la directory dei tag e digitare un nuovo numero e la tua nuova versione è attiva (che è forse utile per qualcuno che legge questo). Nota che non dovresti selezionare la radice del tuo progetto ma tutto il resto o altrimenti creerà quella radice anche sotto i tuoi tag / 2.3.4 che non è quello che vuoi tu desideri che tutto sotto la radice sia nella tua directory / tag.
Vedi la pubblicazione per alcune schermate.
http://wp.leau.co/files/2011/02/image_thumb17.png
Collaboratore stesso di WordPress
Se sei un collaboratore puoi usare lo stesso come sopra ma crei "patch" dalle modifiche apportate. "Patches" è un concetto nel mondo CM, ad esempio sovversione fornisce questo o jazz RTC. Con il tasto destro del mouse "Applica patch" è possibile applicare una patch se si dispone di una patch non ancora applicata al trunk WordPress.
Alcune persone si impegnano anche direttamente nel bagagliaio.
WordPress stesso "Leggi"
Basta creare un progetto 'WordPress' che contiene un checkout della versione / LATEST nel trunk (del codice di sovversione), di nuovo, tramite team> checkout.
Personalmente non lo faccio, ma uso solo un'esportazione dell'ultimo codice (con la forza) per ottenere una directory con l'ultima versione di WordPress (quindi che non rientra in alcuna gestione della versione)
In generale
Dato che hai una certa esperienza con VCS e con domande su SVN: praticamente tutti gli strumenti di versione riguardano il concetto di denominazione delle cose. O meglio dire avere il miglior spazio dei nomi. Puoi mappare la maggior parte dei comandi da CVS, Git, RTC, ClearCase, SourceSafe ecc ... al concetto attorno a questo spazio dei nomi. Dato che hai qualche / poca esperienza con altri strumenti, un po 'più ampio:
Le persone nuove spesso si fissano cieche su determinati comandi o una specifica funzionalità, ma fornire la migliore opzione per posizionare tutti gli elementi necessari in uno spazio dei nomi è la cosa fondamentale.
Quindi, poiché questa è sostanzialmente la funzionalità principale di questi strumenti, il termine "gestione delle versioni" è sbagliato. In realtà è un name-space-manager.
Quindi se hai
/ progetto A / dipartimento B / Team C / membro D / stream E / componente F / elemento G / ramo H / ramo I / versione J
Puoi creare un nome univoco per ogni "cosa". Quanto sopra è un'implementazione di uno spazio dei nomi necessario per un determinato scopo utilizzando uno degli strumenti dello spazio dei nomi.
Quasi tutti i concetti in questo mondo possono essere mappati su questo, quindi il modo in cui PUOI supportare il tuo spazio dei nomi / tassonomia personalizzati dipende dalle capacità del tuo strumento. Quindi ... dipende davvero dai concetti e dalle scelte che hanno fatto i progettisti delle centinaia di strumenti diversi.
In un buon strumento puoi fare clic e vedere questa tassonomia completa in un albero o ingrandire uno di quell'albero.
Questo è il nocciolo: uno strumento che può aiutarti a gestire la complessità (vedi complessità in wikipedia: http://en.wikipedia.org/wiki/Complexity ) dandoti buoni strumenti per gestire la TUA tassonomia CUSTOM. La persona che crea la tassonomia pensando a come impostarla è il gestore della configurazione che scrive un piano chiamato piano di gestione della configurazione, pensando prima a questo.
Immagina semplicemente qualcuno che ti chieda di creare un set di tassonomie personalizzate in WordPress che rappresentino TUTTI gli oggetti nella sua azienda, inclusa la possibilità di farne uscire lo stato com'era in un dato momento. Puoi fare molte scelte di design e ognuno produrrà qualcos'altro in base ad alcune scelte. Alcuni conterranno più funzionalità, altri sono più semplici e quelli più complessi hanno preso decisioni diverse. Questo è "questi strumenti". Quindi non capisco mai le discussioni a livello di strumento sulla gestione delle versioni perché è completamente strano.
Al giorno d'oggi in PHP puoi creare spazi dei nomi creando una gerarchia con directory, applicare convenzioni di denominazione agli oggetti e al loro interno metodi. Se prendi un file che hai inserito in una gerarchia, fai un ulteriore passo avanti. Ne aggiungi uno / dietro e inserisci un numero di versione dietro. Ciò non è nemmeno sufficiente perché si vorrebbe che il team A lavorasse sulla versione 4 del file e il team B che lavorasse su quella versione. Quindi aggiungi un altro / e aggiungi l'ID del ramo. Ecco come si costruisce lo spazio dei nomi. A seconda dello strumento puoi diventare pazzo come vorresti.
Ma significa: se qualcuno viene da te chiedendo "dov'è il documento Z" non puoi dare la risposta. Perché in un sistema di gestione delle versioni "documento Z" non esiste. E anche quando mi dice "documento Z versione 5" non puoi consegnarlo poiché potrebbe significare "documento Z versione 5" del ramo del team 1 o "documento Z versione 5" del ramo del team 2. Si tratta solo di nominare. "document Z version 5" è semplicemente un approccio di denominazione non corretto nello spazio dei nomi definito.
In Subversion puoi farlo solo in modo limitato, in modo da renderlo semplice da capire. Alcuni concetti abbinati a questo:
"versione"
Una versione è una revisione di un determinato elemento. Ad esempio, wp-config.php versione 5. In uno strumento come ClearCase puoi anche vedere singole versioni di elementi e "commettere" singoli file (ma eseguire anche commit atomici o cambiare set o altro).
Nelle versioni di gestione di Subversion è più limitato:
- una serie di modifiche apportate localmente in una sola volta ti " impegna ", il che significa che quella serie completa di "modifiche" viene impegnata atomicamente e l'intera base ottiene un nuovo numero di versione. Questo è il numero di versione che vedi nel sito di sovversione di WordPress.
- quindi non è possibile apportare localmente più modifiche su 1 file e farle trattare tutte come nuove versioni singolari come in clearcase. tutte le modifiche apportate localmente a quel 1 file o qualsiasi altro vengono inviate in una volta sola e ottengono quel "nuovo nome univoco".
- se non si ha accesso al repository (diritti) è possibile apportare una serie di modifiche e salvarle in una "patch". È quindi possibile inviare quella patch a qualcuno come un gestore dell'integrazione o persino un gestore della build che lo applica al repository. Strumenti come ad esempio RTC supportano anche "patch". Quindi una persona crea una patch e un'altra applica la patch. Dovresti considerare questo davvero come la parola significa "una patch", quindi non il caso d'uso predefinito di sviluppo del codice.
- invece di / branch N / hello.doc / versione 25 ci sono anche etichette come / branch N / hello.doc / LATEST o / HEAD. In alcuni sistemi di gestione delle versioni è possibile applicare etichette complesse e quindi scrivere script lavorando su queste etichette.
lavorando su una versione
In Subversion il caso d'uso predefinito è semplicemente scaricare tutte le cose sul disco rigido da un checkout del repository , lavorare sulle cose e quindi impegnarsi e quindi affrontare tutte le modifiche apportate da altre persone dopo aver risolto i conflitti. Questi concetti vengono visualizzati nella GUI. Se vuoi impedire che qualcun altro modifichi anche il tuo esempio hello.doc, allora BLOCCATO significa: nessun altro dovrebbe essere in grado di modificarlo.
VERAMENTE non mi piace quell'idea :( IMHO è una pessima pratica. Per confronto e comprensione: in ClearCase un checkout è più o meno paragonabile a un lock e un checkin è un commit (in sovversione checkin è un alias per commit) Questo è il caso d'uso predefinito in ClearCase in cui supporta anche hijack che è lo stesso di un check di sovversione ma poi su file selezionati. IMHO questo è molto più pulito. Inoltre, anche quando fai il checkout in ClearCase ti offre 3 opzioni: altro le persone potrebbero non lavorarci (ad es. con i documenti di parole), altre persone potrebbero lavorarci su se veramente necessario e "tutti potrebbero lavorarci" (ad es. con file di codice sorgente) Quindi ... questo è ciò che significa checkout, lock and commit in SVN.
componenti e rivestimento di base
In strumenti come RTC e ClearCase è possibile raggruppare elementi in componenti. Potente poiché questi componenti fanno parte dello spazio dei nomi e ottengono le proprie versioni baselandoli. Ad esempio, il componente "WordPress" ottiene la versione 4.53 di base. Queste linee di base sono quindi oggetti in se stessi che possono quindi ottenere metadati come "in test". Tuttavia SVN non ha NESSUNO questo. Così... :
tag
In SVN (e così nel sito di WordPress) vedi le directory con i numeri in una directory generale chiamata 'tag'. Un'idea alternativa. Basta prendere un determinato repository e scaricarlo (basato su file) in una directory tag / 3.2.4. Questo è tutto. Non ha alcuna relazione nello spazio dei nomi di gestione delle versioni, ecc ... solo una semplice directory .... SIGH ..... Impossibile IMHO per eseguire qualsiasi gestione della configurazione con questo tipo di strumento. Quindi non è un oggetto metadati in cui è possibile eseguire lo script e assegnare proprietà e fare le cose più selvagge no ... è solo una directory ............. In RTC per il confronto è possibile fare un ' istantanea "di una determinata linea di base per supportare anche questo caso d'uso. In ClearCase UCM dovresti creare un nuovo ramo / flusso di una determinata linea di base e quindi "visualizzarlo".
rami
Questo non è usato nell'ambiente WordPress per quanto ne so, ma forse mi sbaglio e ci sono team che lo fanno per le versioni di WordPress per il backup delle modifiche delle porte alle versioni precedenti. Quindi non lo so, forse qualcun altro lo sa.
Questo è usato per l'albero dello spazio dei nomi. Per avere 2 team che lavorano sullo stesso codice puoi dire "in inglese" \ team 1 \ hello.doc e \ team 2 \ hello.doc. Entrambe le squadre poi funzionano e dopo un po 'hai \ team 1 \ hello.doc \ versione 51 e \ team 2 \ hello.doc \ versione 23. (quindi il team 1 ha realizzato 51 versioni e il team 2 ne ha realizzate 23). Ora hai la possibilità di unirti dalla squadra di filiale 1 alla squadra di filiale 2 e otterrai fusioni nella squadra 2 ma alla fine la squadra 2 avrà tutti i cambiamenti della squadra 1 (versione 24) e le singole filiali mostreranno comunque il lavoro per ciascuno di loro.
In RTC e ClearCase questo non è usato ma un oggetto più avanzato chiamato "stream" (per confronto). Da una prospettiva bassa puoi considerarli gli stessi MA ....... quando sei nella vita reale i tuoi rami conterranno MOLTE cose. Quindi nel mondo reale dovresti prendere appunti, note di rilascio, documentazione ecc ... Per migliorare questo un flusso contiene non solo il "codice" ma anche i "cambiamenti" in modo da sapere che RFC23 era circa la versione 34,32 e 56 e puoi rilasciarli separatamente.
Se vuoi impostare le cose nel modo giusto, dai a OGNI persona uno o più flussi / rami personali. Quindi possono effettuare il check-in / commit e il checkout da lì e non disturba nessuno. solo quando qualcuno è pronto "consegnano" le loro cose ad esempio al flusso del team e al flusso del team recapita al flusso di integrazione ecc ... In WP probabilmente le versioni sono filiali ma per persone normali: lavorano tutte nello stesso ramo. Uno svantaggio poiché i "progetti di test" sono quindi in c: \ temp e non sotto la gestione delle versioni e non è possibile avere un gruppo di persone che lavora temporaneamente sulla funzione X che sarà necessario solo in 5 versioni.
il mondo ideale e i compromessi
se hai \ team1 \ hello.doc e qualcuno copia in \ team2 \ Hello.doc anche questo è BAaaaaad. Da ora abbiamo 2 elementi con ID diversi in cui l'utente pensa che siano uguali ma il sistema li tratta come non uguali. Questo si chiama "gemelli malvagi" e non dovresti mai farlo in questo tipo di ambiente. Unisci o base di rami sempre. Se capisci i gemelli malvagi capisci i rami (perché questo è male: perché in un'unione saranno trattati come 2 entità diverse mentre vuoi che siano trattati come gli stessi) (o diverso tipo di comportamento in sistemi diversi). Se un nuovo utente rovina qualcosa, è per lo più. 'Ho appena eliminato hello.doc e l'ho copiato in' argh
I CAMBIAMENTI
SVN non offre supporto per questo MA ci sono strumenti che puoi integrare con esso per supportare un qualche tipo di gestione integrata delle modifiche / ALM. In strumenti come la variante ClearCase-UCM o RTC non puoi cambiare 1 lettera senza che ci sia un difetto, RFC, ticket, ecc ... In SVN quando commettipuoi digitare una descrizione per il tuo commit atomico. Significato: dovresti provare ad avere cambiamenti in pezzi "patchable" in altre parole: fai un impegno atomico per difetto / cambiamento per avere un po 'quel comportamento. (ma ovviamente non è da nessuna parte in seguito tutti collegati in un albero di denominazione come nel database ClearCase) (in modo da poter automatizzare le note di rilascio o aiutare il povero che è gestore distribuzione a ottenere tonnellate di nuovi set di codice, modifiche, rilasci e tentativi mescolarlo insieme senza un vero strumento per dargli un'idea di cosa sia realmente).
Poiché SVN non supporta la gestione delle modifiche WordPress configurato per utilizzare TRAC: http://core.trac.wordpress.org/ come sai perché vivi lì :)
Sento che TRAC è lì perché manca uno strumento reale come ClearCase o RTC con modifiche integrate come oggetti (sì, quello contro cui si programma). Quindi hai uno strumento in cui discutere e inviare una "sorta di" modifica impostata su (mentre manca anche quel concetto). Quindi queste sono le "patch" solo un mucchio di file senza nessuno dei metadati che ti aspetteresti in un buon sistema (quindi ora sono nello stato di Grumpy). Il numero di TRAC è importante poiché si tratta dell'ID complessivo nella struttura dei nomi collegato ad alcune modifiche.
Fornire modifiche
Questo è qualcosa da scrivere in un articolo di blog separato. In breve: nel mondo ideale vorresti selezionare le modifiche che vuoi "consegnare" (o un altro concetto) e quindi non preoccuparti di file, directory (versioni di). Devi solo "fornire RFC 3 e 5". Ecco come funziona ClearCase UCM o RTC. In SVN / base clearcase si 'impegna' un mucchio di file in cui speriamo che tu abbia preso la decisione giusta. Questa è una grande differenza e una importante. (questo è il motivo per cui SVN è usato principalmente insieme integrato ad esempio con jira / clearquest / ecc ... per raggiungere questo comportamento). Patching .... non sta fornendo è più da 1 stream a un altro come una 'patch' uhm.
Esterni
In altri strumenti questo in modo diverso in SVN è più semplice: se hai codice da una parte che non è tua, puoi trattarlo come una versione esterna gestita e ... per tornare al concetto di base: vuoi dire che quello la parte non rientra nella responsabilità dello spazio dei nomi poiché si tratta solo di nominare. MA anche se è esterno, è sotto la tua responsabilità.
Nella GUI non c'è flusso di lavoro nel normale "mouse destro" ma è definito nella struttura del progetto. Quindi fa parte della tua definizione.
Questo concetto, se utilizzato, è definito nella CMP IEEE come richiesto per definire (Vedi sotto)
Integrazione e fusioni
Come detto. Il paradigma dietro SVN è quello di ottenere roba localmente, fare il tuo lavoro e poi impegnarti e poi avere la ***. Nella GUI ottieni esattamente gli stessi strumenti della maggior parte degli altri. Qui dovresti davvero comprendere l'unione a tre, l'unione a due e la differenza tra conflitti che possono essere risolti automaticamente e conflitti che non possono essere risolti automaticamente. Quest'ultimo rientra quindi in 2 classi: quelli in cui lo strumento può proporti quale sarebbe il buon risultato finale e quelli in cui non sa quale sarebbe il fine. Hai chiesto informazioni sulla GUI ma sulla riga di comando ottieni file di informazioni su cosa dovresti correggere / unire prima di eseguire il commit.
Molto di più per un articolo di blog. (ad es. Sviluppo open source contro sviluppo aziendale e creazione di gestori e gestori di integrazione in quanto è necessario fare diverse scelte qui).
Ultimo ma non meno importante il CMP
Quello che chiedi è un piano di gestione della configurazione per WordPress. Questo è un documento IEEE. Significato: qualunque dei milioni di piani di gestione della configurazione che trovi su Google sono tutti validi contro l'IEEE specificato (diverse versioni) della CMP.
Proprio come (es. HTTP) RFC c'è l'IEEE CMP.
Questo piano contiene sezioni definite come "come trattare gli esterni" e "come appare lo spazio dei nomi, come recuperiamo gli oggetti e come li riproduciamo", ruoli, responsabilità ecc ...
Da questo CMP è quindi possibile creare istruzioni di lavoro. Chiunque desideri sapere quali sono le regole può quindi leggere il CMP.
In un contesto open source spesso manca il ruolo "Configuration Manager". Quindi ti manca anche il piano di gestione della configurazione.
Diverso da un RFC pubblico (ad es. URI o HTTP) Devi pagare per il documento standard IEEE ma ... se Google lo troverai qua e là.
Via di consegna
In una via di consegna avresti una squadra che pensa a nuove idee imprenditoriali. Hai un dipartimento di manutenzione che ottiene un gazillion di bug di produzione nel loro sistema. Avresti più team che lavorano sullo stesso codice. e in ogni sotto-strada avresti un team di requisiti che definisce i requisiti. Un team di architettura diviso in un team funzionale e un team operativo (i casi d'uso vanno al team funzionale e non funzionali al team operativo). Avresti spesso diverse versioni parallele live in un ambiente di unit test, ambienti di accettazione, ambienti di carico e stress test, ambienti di test funzionali, ambienti di test pre-produzione e ambienti di produzione.
In tutti loro sono versioni che sono tutte tracciate l'una con l'altra.
una versione su un ambiente di test specifico è collegata a una serie di versioni collegate a un RFC specifico e questa è collegata a una versione specifica di un requisito. Il requisito è quindi collegato a una versione specifica di un set di test. TUTTI rientrano nella gestione delle versioni.
In WP con SVN / TRAC non ho ancora trovato il database dei requisiti e il database delle versioni dei requisiti. (in modo da poter eseguire analisi di impatto e vedere quale codice cambia se si modifica 1 requisito) (e che in una nuova versione è possibile stampare quali requisiti sono cambiati). Ho visto singoli articoli in TRAC in cui sono stati creati collegamenti ad altri singoli elementi in TRAC nei commenti. Inoltre non ho visto tracciabilità tra gli articoli TRAC e il codice se non nei commenti. Quindi significa che le persone stanno facendo molto nella loro testa ed è molto dipendente da una comunità attiva o da sviluppatori chiave poiché hanno molto di questo nel loro cervello.
Ma questo sta andando lontano dall'argomento sogghigno
OSLC per ALM
Solo un'altra nota per questa storia: non sarebbe bello se ci fosse un pacchetto di standard per tutti questi strumenti di gestione del ciclo di vita delle applicazioni (ALM)? Qualcuno ci ha pensato e ora ci sono degli standard in modo che tutti i concetti siano messi a un livello di astrazione più elevato e quindi implementati negli strumenti. Google: OSLC per ALM. (in modo che tutti gli strumenti possano parlare tra loro e per l'utente: che tu li capisca tutti capendo il livello di astrazione).
CALMA
Ancora un passo in più se hai tempo: il mondo si sta ora dirigendo verso C / ALM, una prossima generazione di prodotti in cui i processi e gli strumenti sono una cosa integrata in modo da non dover più chiederti quale sia il processo. Il primo prodotto di questa generazione è RTC. Quindi, se capisci bene SVN o capisci ClearCase o Jira o Trac o ANT o Agile o RUP o iRUP o qualunque sia il processo, la gestione della versione, la gestione delle modifiche, la gestione delle build, avrai bisogno di tutto questo per capire RTC perché tutto ciò è combinato in una cosa perché si legano tutti insieme e questo su se stesso si interfaccia attraverso OSLC in modo che uno di questi strumenti più vecchi possa "collegarsi".
Ma ora sono davvero fuori tema.