Come usare SVN, Branch? Etichetta? Tronco?

Stavo cercando su Google un po 'e non riuscivo a trovare una buona guida per principianti a SVN , non nel senso di "come posso usare i comandi"; Come controllo il mio codice sorgente?

Quello che vorrei chiarire sono i seguenti argomenti:

• Quanto spesso ti impegni? Ogni volta che si preme Ctrl+ s?
• Che cos'è una filiale e che cos'è un'etichetta e come le controlli?
• Cosa succede in SVN? Solo codice sorgente o condividi anche altri file qui? (Non considerato file con versione ..)

Non ho idea di cosa sia il ramo e il tag, quindi non conosco lo scopo, ma la mia ipotesi selvaggia è che carichi roba nel bagagliaio e quando fai una build importante la sposti nel ramo? Quindi, qual è considerata una build importante in questo caso?

Il libro di sovversione è un'eccellente fonte di informazioni sulle strategie per la disposizione del deposito, la ramificazione e l'etichettatura.

Guarda anche:

Continui lo sviluppo in un ramo o nel tronco

Strategie di ramificazione

Mi sono posto le stesse domande quando siamo venuti qui per implementare Subversion - circa 20 sviluppatori si sono sparsi per 4-6 progetti. Non ho trovato nessuna buona fonte con '' la risposta ''. Ecco alcune parti di come la nostra risposta si è sviluppata negli ultimi 3 anni:

- impegnarsi tutte le volte che è utile; la nostra regola empirica è impegnata ogni volta che hai svolto un lavoro sufficiente che sarebbe un problema doverlo rifare se le modifiche andassero perse; a volte mi impegno ogni 15 minuti circa, altre volte potrebbero essere giorni (sì, a volte mi ci vuole un giorno per scrivere 1 riga di codice)

- utilizziamo i rami, come suggerito da una delle tue precedenti risposte, per diversi percorsi di sviluppo; in questo momento per uno dei nostri programmi abbiamo 3 rami attivi: 1 per lo sviluppo principale, 1 per lo sforzo ancora incompiuto di parallelizzare il programma e 1 per lo sforzo di revisionarlo per utilizzare file di input e output XML;

- usiamo a malapena i tag, anche se pensiamo che dovremmo usarli per identificare i rilasci in produzione;

Pensa allo sviluppo che procede lungo un unico percorso. A un certo momento o lo stato di sviluppo del marketing decide di rilasciare la prima versione del prodotto, quindi si pianta una bandiera nel percorso etichettato '1' (o '1.0' o che cosa hai). In qualche altro momento una scintilla luminosa decide di parallelizzare il programma, ma decide che ci vorranno settimane e che le persone vogliono continuare a percorrere la strada principale nel frattempo. Quindi costruisci un bivio nel percorso e diverse persone vagano giù per le diverse forcelle.

Le bandiere nella strada sono chiamate "tag", e le forcelle nella strada sono dove si dividono i "rami". Occasionalmente, anche, i rami tornano insieme.

- mettiamo tutto il materiale necessario per creare un eseguibile (o sistema) nel repository; Ciò significa almeno il codice sorgente e creare file (o file di progetto per Visual Studio). Ma quando abbiamo icone, file di configurazione e tutto il resto, questo va nel repository. Parte della documentazione si trova nel repository; sicuramente fa qualsiasi documentazione come i file di aiuto che potrebbero essere parte integrante del programma, ed è un posto utile dove mettere la documentazione per gli sviluppatori.

Abbiamo anche messo gli eseguibili di Windows per le nostre versioni di produzione lì, per fornire un unico posto per le persone in cerca di software: le nostre versioni di Linux vanno su un server, quindi non è necessario memorizzarle.

- non richiediamo che il repository sia sempre in grado di fornire una versione più recente che viene compilata ed eseguita; alcuni progetti funzionano in questo modo, altri no; la decisione spetta al project manager e dipende da molti fattori, ma penso che si guasta quando si apportano modifiche importanti a un programma.

* How often do you commit? As often as one would press ctrl + s?

Più spesso possibile. Il codice non esiste a meno che non sia sotto il controllo del codice sorgente :)

I commit frequenti (da allora in poi set di modifiche più piccoli) ti consentono di integrare facilmente le modifiche e aumentare le possibilità di non interrompere qualcosa.

Altre persone hanno notato che dovresti impegnarti quando hai un pezzo di codice funzionale, tuttavia trovo utile impegnarsi leggermente più spesso. Poche volte ho notato che utilizzo il controllo del codice sorgente come meccanismo di annullamento / ripetizione rapido.

Quando lavoro sul mio ramo preferisco impegnarmi il più possibile (letteralmente ogni volta che premo ctrl + s).

* What is a Branch and what is a Tag and how do you control them?

Leggi il libro SVN : è un punto da cui iniziare quando si impara SVN:

• Che cos'è un ramo?
• tag

* What goes into the SVN?

Documentazione, piccoli binari richiesti per la compilazione e altre cose che hanno un certo valore vanno al controllo del codice sorgente.

Ecco alcune risorse su frequenza di commit, messaggi di commit, struttura del progetto, cosa mettere sotto controllo del codice sorgente e altre linee guida generali:

• Best Practices of Version Control (il mio blog)
• Check in Early, Check in Spesso (Coding Horror) (i commenti qui contengono molti buoni consigli)
• La politica di commit di KDE

Queste domande Stack Overflow contengono anche alcune informazioni utili che potrebbero essere di interesse:

• Organizzazione della base di codice sorgente quando si mescolano due o più lingue (come Java e C ++)
• Suggerimenti per un buon messaggio di commit: formato / linea guida?
• Con quale frequenza eseguire modifiche al controllo del codice sorgente?
• Imparare il controllo delle versioni e impararlo bene

Per quanto riguarda i concetti di base di Subversion come branching e tagging, penso che questo sia molto ben spiegato nel libro di Subversion .

Come puoi capire dopo aver letto un po 'di più sull'argomento, le opinioni delle persone sulle migliori pratiche in questo settore sono spesso variabili e talvolta contrastanti. Penso che l'opzione migliore per te sia leggere cosa fanno gli altri e scegliere le linee guida e le pratiche che ritieni più sensate per te.

Non penso sia una buona idea adottare una pratica se non ne capisci lo scopo o non accetti la logica alla base. Quindi non seguire alcun consiglio alla cieca, ma piuttosto prendere una decisione su ciò che pensi funzionerà meglio per te. Inoltre, sperimentare diversi modi di fare le cose è un buon modo per imparare e scoprire come ti piace lavorare. Un buon esempio di ciò è come strutturi il repository. Non esiste un modo giusto o sbagliato per farlo, ed è spesso difficile sapere quale modo preferisci fino a quando non li hai effettivamente provati in pratica.

La frequenza di commit dipende dal tuo stile di gestione del progetto. Molte persone si astengono dal commettere se si romperà la build (o la funzionalità).

I rami possono essere utilizzati in due modi, in genere: 1) Un ramo attivo per lo sviluppo (e il tronco rimane stabile), oppure 2) rami per percorsi di sviluppo alternativi.

I tag vengono generalmente utilizzati per identificare le versioni, quindi non si perdono nel mix. La definizione di "rilascio" dipende da te.

Penso che il problema principale sia che l'immagine mentale del controllo del codice sorgente sia confusa. Di solito abbiamo trunk e rami, ma poi otteniamo idee non correlate di tag / rilasci o qualcosa che influisca su ciò.

Se usi più completamente l'idea di un albero, diventa più chiaro, almeno per me lo è.

Otteniamo il tronco -> rami rami -> produciamo frutta (tag / rilasci).

L'idea è di far crescere il progetto da un tronco, che quindi crea rami quando il tronco è abbastanza stabile da contenere il ramo. Quindi quando il ramo ha prodotto un frutto, lo prendi dal ramo e lo rilasci come tag.

I tag sono essenzialmente risultati finali. Considerando che tronco e rami li producono.

Come altri hanno già detto, il libro SVN è il miglior punto di partenza e un ottimo riferimento dopo aver ottenuto le gambe. Ora, alle tue domande ...

Quanto spesso ti impegni? Ogni volta che si preme ctrl + s?

Spesso, ma non così spesso come si preme ctrl + s. È una questione di gusti personali e / o politica del team. Personalmente direi commit quando completi un pezzo di codice funzionale, per quanto piccolo.

Che cos'è una filiale e che cos'è un'etichetta e come le controlli?

Innanzitutto, trunk è il luogo in cui svolgi il tuo sviluppo attivo. È la linea principale del tuo codice. Un ramo è una deviazione dalla linea principale. Potrebbe essere una deviazione maggiore, come una versione precedente, o solo una piccola modifica che vuoi provare. Un tag è un'istantanea del tuo codice. È un modo per allegare un'etichetta o un segnalibro a una particolare revisione.

Vale anche la pena ricordare che in sovversione, trunk, rami e tag sono solo convenzionali. Nulla ti impedisce di lavorare nei tag o di avere rami che sono la tua linea principale o di ignorare tutti insieme lo schema tag-branch-trunk. Ma, a meno che tu non abbia un'ottima ragione, è meglio attenersi alle convenzioni.

Cosa succede in SVN? Solo codice sorgente o condividi anche altri file qui?

Anche una scelta personale o di squadra. Preferisco tenere tutto ciò che riguarda la build nel mio repository. Che include i file di configurazione, script di build, file multimediali correlati, documenti, ecc Si dovrebbe non il check-nei file che devono essere diverso sul computer di ogni sviluppatore. Né è necessario controllare i sottoprodotti del codice. Sto pensando principalmente a costruire cartelle, file oggetto e simili.

Eric Sink, che è apparso sul podcast SO # 36 nel gennaio 2009, ha scritto un'eccellente serie di articoli con il titolo Source Control How-to .

(Eric è il fondatore di SourceGear che commercializza una versione plug-compatibile di SourceSafe, ma senza l'orrore.)

Solo per aggiungere un altro set di risposte:

• Mi impegno ogni volta che finisco un lavoro. A volte è un piccolo bugfix che ha appena cambiato una riga e mi ci sono voluti 2 minuti per farlo; altre volte vale due settimane di sudore. Inoltre, come regola generale, non commetti nulla che interrompa la build. Quindi, se ti ci è voluto molto tempo per fare qualcosa, prendi l'ultima versione prima di impegnarti e vedi se le tue modifiche infrangono la build. Certo, se vado a lungo senza impegnarmi, mi mette a disagio perché non voglio perdere quel lavoro. In TFS uso questa cosa carina come "scaffali" per questo. In SVN dovrai aggirare il problema in un altro modo. Forse crea il tuo ramo o fai il backup di questi file manualmente su un altro computer.
• I rami sono copie di tutto il tuo progetto. L'illustrazione migliore per il loro uso è forse il controllo delle versioni dei prodotti. Immagina di lavorare a un grande progetto (diciamo, il kernel Linux). Dopo mesi di sudore sei finalmente arrivato alla versione 1.0 che rilasci al pubblico. Dopo di che inizi a lavorare sulla versione 2.0 del tuo prodotto, che sarà molto meglio. Ma nel frattempo ci sono anche molte persone là fuori che usano la versione 1.0. E queste persone trovano bug che devi correggere. Ora, non è possibile correggere il bug nella prossima versione 2.0 e spedirlo ai client - non è affatto pronto. Invece devi estrarre una vecchia copia del sorgente 1.0, correggere il bug lì e spedirlo al popolo. Ecco a cosa servono i rami. Quando hai rilasciato il 1. 0 versione hai creato un ramo in SVN che a quel punto ha creato una copia del codice sorgente. Questo ramo è stato chiamato "1.0". Quindi hai continuato a lavorare sulla versione successiva nella tua copia di origine principale, ma la copia 1.0 è rimasta lì com'era al momento del rilascio. E puoi continuare a correggere i bug lì. I tag sono solo nomi associati a revisioni specifiche per facilità d'uso. Si potrebbe dire "Revisione 2342 del codice sorgente", ma è più facile riferirsi ad esso come "Prima revisione stabile". :)
• Di solito metto tutto nel controllo del codice sorgente direttamente correlato alla programmazione. Ad esempio, dal momento che sto realizzando pagine web, metto anche immagini e file CSS nel controllo del codice sorgente, per non parlare dei file di configurazione, ecc. La documentazione del progetto non va lì, tuttavia in realtà è solo una questione di preferenza.

Altri hanno affermato che dipende dal tuo stile.

La grande domanda per te è quanto spesso "integri" il tuo software. Lo sviluppo guidato dai test, Agile e Scrum (e molti, molti altri) si basano su piccoli cambiamenti e integrazione continua. Predicano che vengano apportate piccole modifiche, tutti trovano le pause e le riparano continuamente.

Tuttavia, su un progetto più ampio (pensa a governo, difesa, 100k + LOC) non puoi semplicemente utilizzare l'integrazione continua in quanto non è possibile. In queste situazioni potrebbe essere meglio usare la ramificazione per fare molti piccoli commit ma riportare nel trunk SOLO ciò che funzionerà ed è pronto per essere integrato nella build.

Un avvertimento con la ramificazione è che se non sono gestiti correttamente, può essere un incubo nel tuo repository per ottenere lavoro nel bagagliaio, poiché tutti si stanno sviluppando da punti diversi sul bagagliaio (che per inciso è uno dei maggiori argomenti per integrazione continua).

Non esiste una risposta definitiva a questa domanda, il modo migliore è lavorare con il tuo team per trovare la migliore soluzione di compromesso.

Controllo versione con Subversion è la guida per principianti e esperti.

Non penso che tu possa usare Subversion in modo efficace senza leggere almeno i primi capitoli di questo.

Per l'impegno, utilizzo le seguenti strategie:

• impegnarsi il più spesso possibile.

• Ogni modifica / correzione di funzionalità dovrebbe ottenere il proprio commit (non eseguire il commit di più file contemporaneamente poiché ciò renderebbe poco chiara la cronologia di quel file, ad esempio se cambio un modulo di registrazione e un modulo GUI in modo indipendente e commetto entrambi contemporaneamente, entrambe le modifiche saranno visibili in entrambe le cronologie dei file. Ciò rende difficile la lettura di una cronologia dei file),

• non interrompere la creazione di alcun commit: dovrebbe essere possibile recuperare qualsiasi versione del repository e crearlo.

Tutti i file necessari per la creazione e l'esecuzione dell'app devono essere in SVN. File di test e simili non dovrebbero, a meno che non facciano parte dei test unitari.

Molti buoni commenti qui, ma qualcosa che non è stato menzionato sono i messaggi di commit. Questi dovrebbero essere obbligatori e significativi. Soprattutto con la ramificazione / fusione. Ciò ti consentirà di tenere traccia delle modifiche rilevanti per le funzionalità dei bug.

per esempio svn commit . -m 'bug #201 fixed y2k bug in code'dirà a chiunque guardi alla storia a cosa servisse quella revisione.

Alcuni sistemi di tracciamento dei bug (ad es. Trac) possono cercare nel repository questi messaggi e associarli ai ticket. Ciò rende molto semplice capire quali cambiamenti sono associati a ciascun biglietto.

La politica del nostro lavoro va in questo modo (team multi-sviluppatore che lavora su un framework orientato agli oggetti):

• Aggiorna da SVN ogni giorno per ottenere le modifiche del giorno precedente

• Impegnati quotidianamente, quindi se sei malato o assente il giorno successivo (s) qualcun altro può facilmente prendere il posto da dove hai interrotto.

• Non commettere codice che rompe qualcosa, poiché ciò avrà un impatto sugli altri sviluppatori.

• Lavora su piccoli pezzi e impegnati ogni giorno CON COMMENTI SIGNIFICATIVI!

• In team: mantenere un ramo di sviluppo, quindi spostare il codice di pre-release (per il QA) in un ramo di produzione. Questo ramo dovrebbe avere un codice completamente funzionante.

Il manuale TortoiseSVN TSVN si basa sul libro di sovversione , ma è disponibile in molte più lingue.

Penso che ci sia un doppio modo per eseguire il commit della frequenza:

1. Impegnarsi molto spesso, per ogni metodo implementato, piccola parte del codice, ecc.
2. Commettere solo parti di codice completate, come moduli, ecc.

Preferisco il primo: poiché l'utilizzo del sistema di controllo del codice sorgente è molto utile non solo per il progetto o l'azienda, il primo è utile per lo sviluppatore. Per me la migliore caratteristica è quella di ripristinare tutto il codice durante la ricerca della migliore implementazione dell'attività assegnata.