Usi di sovversione [chiuso]

Question

Ho appena iniziato a utilizzare " Subversion " con "quotazione client Tortoise SVN" per uno dei miei progetti opensource ospitato su " Google Code " ;. Vorrei ottenere alcune migliori pratiche sull'uso. Sto seguendo la struttura di cartelle predefinita (trunk, branch, tag). Di seguito sono riportate le domande

1. Quando eseguirai il check-in iniziale? È solo dopo aver terminato una serie di funzionalità o dal primo giorno di sviluppo?
2. In quale directory va il check-in iniziale? È dentro " tronco " oppure fai il check-in in " branch " e unire in "trunk" una volta completata una funzione. In questo caso "tronco" sarà vuoto fino al completamento della funzione.
3. Ogni volta che vengono apportate modifiche, effettuerai il check-in nel "trunk" direttamente? In caso contrario, la tua copia di lavoro utilizzerà sempre " branch " directory, giusto?

Qualsiasi aiuto sarebbe apprezzato.

Answer 1

1. Ti consiglio di fare il check-in dei tuoi file prima di iniziare a fare pesanti modifiche ad essi ( fai il check-in in anticipo, fai il check-in spesso ).

2. Dipende, ad alcune persone piace avere il trunk stabile , lavorare nei rami e quindi ricollegare i rami al tronco quando le funzionalità sono pronte, ma puoi anche impegnarti direttamente a il tronco.

3. Dipende anche da come lavorerai e cosa ti piacerebbe avere nel trunk (l'ultima versione stabile o l'ultima versione bleeding edge).

Answer 2

Suggerisco di fare il check-in in anticipo e spesso.

Esistono molti modi per farlo, ma il più comune con cui ho lavorato con successo è lavorare fuori da un ramo di sviluppo e unirmi al trunk quando arrivi a un punto stabile (versioni di versioni minori, pietre miliari, ecc.)

Se non lo hai già fatto, consulta il libro rosso , è un'ottima risorsa per le informazioni svn.

Answer 3

Quando creo un nuovo progetto da zero, di solito lo faccio in un'area utente in SVN come

/svn/users/me/project1

questo perché la maggior parte dei progetti inizia come prototipi da buttare via e raramente uso i rami per questi. Una volta che un progetto diventa ufficiale e si avvicina, è il primo "prototipo" rilascio lo migrerò sul suo repository

/svn/project1/trunk

L'uso dei rami richiede un po 'di lavoro extra, quindi non li usiamo a meno che non siano necessari. Questo è quando più persone stanno lavorando allo stesso progetto e le collisioni sono spesso o sto lavorando a una funzione che potrei decidere di ripristinare e buttare via. Se fatto in un ramo, posso semplicemente scegliere di non unire ed eliminarlo.

Answer 4

Tutte le risposte suggeriscono che fai il check-in in anticipo, fai il check-in spesso, non potrei essere più d'accordo. Questo è tutto ciò che dirò a riguardo. Tuttavia, ho letto il riassunto come: Che tipo di usi può adattarsi Subversion? Quindi ecco una risposta per questo.

Ho letto delle aziende che usano Subversion come repository delle loro applicazioni. Quindi, dicono al server che vogliono installare la versione X dell'applicazione Y. Quindi il server esegue un aggiornamento sul server SVN. E hanno anche memorizzato i file di configurazione anche lì. E tutte le modifiche apportate alla configurazione (tramite un'interfaccia Web separata per i clienti finali) sono state quindi impegnate nel repository di configurazione SVN. È brillante. "Naturalmente questi ragazzi stavano usando MS Power Shell su Win2k3, ma la tecnica può essere applicata altrove.

Answer 5

Effettua il check-in IMMEDIATAMENTE, non in anticipo. Anche se non hai altro da impegnare di un file di testo ad-hoc contenente brainstorms e qualche codice psuedo orribilmente criptico, commettilo.

Io (come molti) trovo progetti come i tuoi mentre faccio una ricerca del codice o cerco un programma che fa quello che voglio. Leggerò la tua prima pagina, quindi sfoglio immediatamente il tuo trunk SVN per vedere cosa stai facendo.

Se hai il codice zero nel trunk, probabilmente dimenticherò tutto di te. Se hai almeno un file che spiega il tuo progetto e un po 'di codice psuedo, probabilmente inizierò a inviarti patch che mostrano le mie idee.

Un progetto con un repository vuoto urla "prurito che non sarà mai graffiato" .. quindi spingi qualcosa il prima possibile.

Dopodiché, commetti spesso. Mi piace prendere molti piccoli impegni ordinati, quindi è facile tenere traccia delle regressioni e ripristinare / correggere le revisioni tossiche.

Answer 6

1. Effettua il check-in dopo aver creato la struttura del progetto / soluzione di base vuota . Vuoto perché in questo stato è in realtà compilabile anche se non ha un codice funzionante. Il principio è quello di mantenere l'intero progetto - almeno - in uno stato compilabile durante lo sviluppo mentre il team commette in modo incrementale e regolarmente modifiche piccole , in modo che la build non si rompa.

2. Non esiste una legge che richieda che il check-in iniziale debba avvenire presso il Trunk o una Branch. È possibile avviare il trunk con un progetto vuoto in modo che sia stabile fin dall'inizio, quindi diramarsi per eseguire lo sviluppo e fonderlo nuovamente nel trunk una volta completato. Puoi anche scegliere di archiviare il progetto vuoto in un Branch e sviluppare la prima funzionalità funzionante o di base prima di unire qualcosa di sostanziale nel Trunk. Ad ogni modo, in base al punto 1, il Trunk dovrebbe essere stabile e di alta qualità . Unisci solo contenuti di alta qualità nel trunk.

3. Ancora una volta non esiste un mandato rigoroso su questo tipo di pratiche. Alcuni team diramano tutto , anche il semplice refactoring delle modifiche ai nomi delle variabili. Alcuni team non conoscono nemmeno la ramificazione / fusione e sviluppano tutto in un singolo ramo (il Trunk). Ogni squadra ha il proprio livello di equilibrio su questo tema. La mia linea guida personale è se ci saranno nuove funzionalità o importanti correzioni di bug o riprogettazione, diramazione per testare. Se si tratta di una correzione minore come errori di ortografia delle stringhe o la visualizzazione di quattro cifre decimali anziché due nella pagina Web, è sufficiente correggere la copia del trunk. Naturalmente, le interpretazioni di "major" contro "minore" stanno andando diversamente, quindi i lead di sviluppo / team dovrebbero stabilire i loro standard. In entrambi i casi, ci devono essere test unitari / di integrazione che accompagnano le modifiche per verificare che la filiale o il trunk funzionino come previsto, il più privi di difetti possibile. La parola chiave da ricordare è sempre "alta qualità, codice testato".