Utilizzo di SVN con più sviluppatori ma senza creare rami

Question

Utilizzo di SVN con più sviluppatori ma senza creare rami

#1 da (5 voti)
#2 da (3 voti)

1

Io sono un informatico che lavora con alcuni studenti in un corso senior di capstone (in effetti, un consulente per una piccola squadra). Li ho incontrati per discutere su come utilizzare il controllo di versione e si trovano in una situazione interessante:

La loro pratica corrente per completare i loro compiti sulle proprie macchine senza commettere. Poi, alla fine di uno scatto agile, tutti impegnano il loro lavoro nello stesso ramo, individuando conflitti di fusione lungo la strada. Ho suggerito che ognuno di loro creava i propri rami personali e si impegnava con loro più frequentemente, ogni volta che ha completato un'attività, e quindi univa i rami alla fine della settimana.

Tuttavia, stanno lavorando al progetto per un client che ospita il repository sul proprio server. Il progetto ha già dozzine di filiali, ognuna delle quali occupa diversi gigabyte di spazio. (Al team è stato detto di lavorare in un particolare ramo, non sul tronco.) Di conseguenza, il team probabilmente avrà bisogno del permesso dal client prima che possa creare nuovi rami, e potrebbe non ottenere quell'autorizzazione.

Se il cliente dice al team di non utilizzare le filiali o ci vuole un po 'per rispondere, come dovrebbero procedere? Quali sono alcuni modelli di utilizzo SVN ragionevoli quando un team non può creare nuovi rami?

version-control branching svn

posta Kevin 16.09.2014 - 17:49

fonte

2 risposte

Leggi altre domande sui tag version-control branching svn

Decidi il tipo di oggetto durante il runtime Dovrebbe essere usato uno stile imperativo se i parametri determinano il risultato?

score 5 · Answer 1

"pattern di utilizzo SVN ragionevoli" è un ossimoro.

Non è possibile creare più rami sul server del cliente: queste sono le regole del cliente e dovrebbero essere rispettate. In ogni caso SVN non è costruito per gestire molti piccoli rami (o qualsiasi numero di rami che è più grande di 1), dal momento che rimarranno nella storia per sempre e dal momento che fonderli per tutto il tempo sarà un dolore.

Se si trattava di Git - pur avendo ancora la regola di un ramo - si poteva utilizzare la natura distribuita di Git e ospitare il proprio server. Gli studenti spingeranno verso quel server, uniranno i rami su quel server e alla fine dello sprint organizzeranno tutto e lo spingeranno dal server dell'università al server del cliente. Il server dell'università sarà il luogo in cui si verificherà tutto il caos di fusione delle diramazioni e il client otterrà i propri commit in un singolo ramo pulito come vogliono.

Sfortunatamente, questo non è Git, quindi non puoi farlo. O puoi?

C'è uno strumento chiamato git-svn che ti permette di spingere e tirare da Git a SVN. Non è buono quanto il puro Git, ma dovrebbe essere sufficiente per spingere dal repository Git che ospiterete sui server dell'università al repository SVN sul server del cliente. Quindi, i tuoi studenti lavoreranno sul server Git con tutte le sue ramificazioni e fusione di bontà, e alla fine dello sprint, dopo aver riposizionato tutto il loro lavoro su una catena lineare di nuovi commit (così SVN potrebbe gestirlo), usano git svn dcommit dal server Git dell'università per trasferire le modifiche al repository SVN del client.

score 3 · Answer 2

Per quanto io odio le risposte su SE che "fanno un modo diverso da quello che sei", dal momento che non sono una vera risposta alla domanda, penso che questa sia la risposta qui.

Il flusso di lavoro che hai descritto è un sistema di controllo della versione distribuito , come git o mercurial, mentre la sovversione è un sistema di controllo della versione centralizzato . I due condividono molte somiglianze, ma hanno anche alcune differenze fondamentali. Cercare di calzare il flusso di lavoro in sovversione è come cercare di bloccare un piolo quadrato in un buco rotondo, e finirà per causare tutti i problemi che risolve.

O è necessario convincere gli studenti ad adottare la religione SVN, o utilizzare un sistema di controllo della versione distribuito tra di loro, e spingere al sistema del cliente separatamente.