Version Control Workflow (Subversion)

0

Ho imparato a usare la sovversione e vorrei semplicemente che qualcuno chiarisse se la mia comprensione fosse corretta o meno?

  1. Crea un repository principale in un dato luogo (sia esso su un server web o locale).
  2. Aggiungi / importa file in detto repository
  3. Esegui il checkout di una copia del repository per lavorare su (o file specifici) in una directory di lavoro.
  4. Modifica / lavoro / aggiungi determinati file.
  5. Commit passa al repository principale (con una nota che spiega le modifiche, sebbene i file modificati vengano annotati, giusto?)
  6. Happy days ...

Supponendo che sia corretto, ho alcune domande.

Quando lavori in un team, cosa succede quando diverse persone lavorano su un progetto e cambiano gli stessi file in modi diversi in un giorno?

Sicuramente quando queste modifiche vengono confermate, si sovrascriveranno reciprocamente?

Come si dovrebbe testare le proprie modifiche prima di tornare al master repo?

Usando PHP per il mio esempio, la directory 'working' dovrebbe essere nella mia cartella xampp in modo da poter eseguire il test prima di eseguire il commit. O ci dovrebbero essere due "master repo" su un server web: uno per i test e uno per la produzione?

Ci scusiamo per le domande per i principianti - non sembrano esserci molti tutorial o documentazione che coprano le basi - Capisco il concetto di controllo del codice sorgente per il ripristino, il monitoraggio delle modifiche e cosa no, ma forse ho bisogno di qualche chiarimento su come i team possono usarlo efficacemente. Se l'idea è che una persona dovrebbe sempre lavorare su un singolo file alla volta che sembra un po '... strano. Se stai lavorando con un'architettura MVC, posso vedere la necessità di avere viste e controller comuni per essere utilizzati da più persone.

    
posta Anonymous 27.09.2011 - 17:03
fonte

3 risposte

3

When working in a team, what happens when several people are working on one project and change the same files in different ways in one day?

Surely when these changes are commit, they will overwrite each other?

No, chi tenta di effettuare il check-in in un secondo momento deve unire modifiche in conflitto prima di confermare le sue modifiche.

How should one go about testing their changes before commiting back to the master repo?

Devi unit test le tue modifiche prima di accettarle. Qualsiasi altro test (integrazione / sistema / accettazione) viene solitamente effettuato sulla versione impegnata.

Or should there be two "master repo's" on a webserver - one for testing and one for production?

Dovresti avere uno e un solo repository di codice sorgente per progetto. Tuttavia, all'interno di quel singolo repository, puoi avere rami diversi della stessa base di codice. E puoi anche distribuire la versione attuale (o diverse versioni) del tuo progetto in diversi ambienti. Devi assolutamente avere (almeno) un ambiente di test vicino al tuo server di produzione.

    
risposta data 27.09.2011 - 17:09
fonte
4

When working in a team, what happens when several people are working on one project and change the same files in different ways in one day?

Hai un conflitto e devi unire. Generalmente il secondo a impegnarsi deve fare la fusione.

Surely when these changes are commit, they will overwrite each other?

No, ci saranno messaggi di errore e dovrai unire le diverse modifiche.

How should one go about testing their changes before commiting back to the master repo?

Test continui e una buona serie di test unitari.

Mai commette il codice rotto noto.

Using PHP for my example, should the 'working' directory be in my xampp folder so I can test before commiting. Or should there be two "master repo's" on a webserver - one for testing and one for production?

Questo è chiamato branching.

    
risposta data 27.09.2011 - 17:10
fonte
0

When working in a team, what happens when several people are working on one project and change the same files in different ways in one day?

Devo riformulare e correggere leggermente le risposte precedenti. Secondo commit non sarà permesso automagicamente, il committer deve aggiornare il suo WC modificato (copia di lavoro) e unire (automaticamente o manualmente - dipende ) cambiamenti in entrata con il proprio. Dopo l'unione, potrà eseguire il commit.

when these changes are commit, they will overwrite each other?

Se intersecano a livello di riga , quindi vinci una sola variazione (risultato di unione manuale), se toccano stringhe diverse - repo memorizzerà 2 (o più) revisioni con tutto modifiche

How should one go about testing their changes before commiting back to the master repo?

Lo stesso che era prima di SCM. QA e unit test non correlati al controllo di versione in comune. E sì, lo sviluppatore può eseguire il commit del codice incompleto del repository - è una questione di politica di utilizzo, non utilizzata SCM

Using PHP for my example, should the 'working' directory be in my xampp folder so I can test before commiting.

Hai (almeno) 2 scelte:

  • Sì, la radice del sito può essere la radice della copia di lavoro (aggiuntiva), che (WC) devono essere aggiornati dopo ogni commit (leggi "post-commit hooks in SVN "): in questo modo è necessario testare sempre l'ultimo codice completo fresco non dimenticare di proteggere le cartelle .svn all'interno di site-tree da spy e ragni
  • Un'altra soluzione è usare svn export per estrarre il codice dal repository e posizionarlo sul sito. Meno sicurezza, ma più mal di testa: se l'aggiornamento di wc può gestire tutte le modifiche nell'albero dei sorgenti (sposta-cancella), esporta solo posiziona l'istantanea corrente, quindi - tutte le eliminazioni | rinomina | le mosse verranno eseguite solo parzialmente, senza pulire i vecchi dati - tu Avremo delete *.*; (x)copy *.* e questo significa più tempo e risorse

Or should there be two "master repo's" on a webserver

Non puoi utilizzare il contenuto del repository direttamente comunque, anche con FSFS non vedi all'interno del repository degli oggetti memorizzati

    
risposta data 27.09.2011 - 18:05
fonte

Leggi altre domande sui tag