Sta usando SVN per lo sviluppo e CM una cattiva pratica?

Naviga le tue risposte
6

Ho un po 'di esperienza con SVN come programmatore / sviluppatore puro. All'interno della mia azienda, tuttavia, utilizziamo SVN come strumento di gestione della configurazione (CM). Pensavo che l'utilizzo di SVN per lo sviluppo allo stesso tempo fosse OK, dal momento che potevamo utilizzare le diramazioni e il trunk per dev e i tag per le versioni. Per me, i tag erano la parte CM, e i rami / tronco erano la parte dev.

Recentemente una persona, che sviluppa codice di alto livello (ma al di fuori del gruppo "puro SW") ha menzionato che la filosofia esistente (mescolando SVN per dev e CM) era sbagliata ... secondo lui. Il suo ragionamento è che pensa che lo strumento CM della società dovrebbe sempre collegarsi al SW eseguibile (quindi i rami infrangerebbero questa regola). Ha anche detto che uno strumento CM non dovrebbe essere un'utilità di backup per commit giornalieri o incrementali. Infine, non gli piace l'idea di dover saltare dalla revisione 143 all'89 per ottenere una copia funzionante ... e inoltre che gli strumenti CM non dovrebbero consentire il ritorno a uno stato rotto. In generale, vuole separare le utility CM e back-up / dev offerte da SVN.

Onestamente, sono nuovo e la persona con questa prospettiva è di anzianità, esperienza e successo, quindi voglio mettere in campo questo dilemma con la base di StackOverflow per vedere se il suo approccio ha un merito.

La mia domanda: l'SVN dovrebbe essere utilizzato puramente per lo sviluppo e un altro strumento per CM (o viceversa)? Perché? Se sì, quali strumenti suggeriresti per questa combo? O pensi che l'integrazione di CM e dev in SVN sia l'approccio migliore? Perché?

Grazie.

Modifica - durante la mia ricerca ho trovato il seguente sito che potrebbe fornire ulteriori motivi per non utilizzare SVN per CM. I punti dell'autore sono validi? Sento che questo è allineato con quello che il mio collega stava dicendo ...

Link: SVN non è CM

    
posta ToTheBeach 03.03.2011 - 16:30
fonte

4 risposte

9

Penso che la domanda migliore sia: cosa stai facendo attualmente per TE? Un sacco di programmatori "esperti" sono pronti a saltare e dire cosa è sbagliato e cosa è giusto, ma a volte ciò che è giusto per loro potrebbe non essere il migliore per te.

Solo qualcosa da prendere in considerazione, IMO se ciò che stai facendo ora sta funzionando bene, non vedo alcun problema nel mantenerlo.

    
risposta data 03.03.2011 - 16:49
fonte
2

Usiamo SVN per developmelemnt e CM. Contrassegniamo la copia di lavoro. Personalmente non vedo alcun problema in questo. Qual è il problema nel saltare da revison 143 a 89 o qualsiasi altra cosa?.

    
risposta data 03.03.2011 - 16:37
fonte
1

I punti che rende sono giusti in quanto tali caratteristiche non appartengono a uno strumento CM. MA SVN non è uno strumento CM autonomo, quindi ha queste caratteristiche e ne hai bisogno per l'aspetto di sviluppo quotidiano.

Se si utilizzano i tag SVN solo per le build di lavoro e nient'altro, tutti i problemi che pone non si applicano alle versioni con tag e chiunque cerchi una build funzionante non dovrebbe andare vicino a trunk o rami. Inserisci i numeri incrementali nei nomi dei tag come RELEASE-1.0.12.

Usando questo approccio le versioni con tag saranno sempre SW eseguibili, avranno numeri incrementali e non saranno coinvolte nei backup giornalieri. Può avere un altro motivo per usare uno strumento separato?

In sintesi mantieni il seguente schema e starai bene usando SVN per entrambi:

trunk + branches = dev

tags = working builds

    
risposta data 03.03.2011 - 19:09
fonte
1

Sembra che non abbia familiarità con le tue convenzioni. Se ha bisogno di usare qualcosa (al contrario di lavorare su qualcosa), allora dovrebbe prendere da un tag. Se ha bisogno dell'ultima versione del codice, allora deve controllare un ramo. Questo è davvero il modo in cui quasi tutti gli SCMS funzionano.

Dà qualche indicazione su quello che considera un "CM" appropriato? Forse sta cercando qualcosa che si trova fuori da Subversion e gestisce build e release, con qualche tipo di processo che promuove file basati su qualche tipo di continuum di stato (dev - > test - > release). Questo è quello che mi viene in mente quando penso a CM, ma non molti negozi sembrano farlo più.

Sembra che il tuo metodo attuale sia ragionevole, penso che ci possa essere un sottotesto non detto dietro il suo atteggiamento.

    
risposta data 03.03.2011 - 19:59
fonte

Leggi altre domande sui tag

Utilizzo di un SDK con codice pazzo Avvio di un gruppo utenti C # /. net [chiuso]