I commit devono essere effettuati solo se la soluzione viene compilata e costruita correttamente? i commit "a metà strada" sono accettabili in cambiamenti molto grandi che lasciano il codice non funzionante per dire, alcune ore?SVN Regolamenti di commit
Sì, è accettabile.
Il controllo versione è per controllo versione; non backup. Dovresti avere qualcosa di separato da utilizzare per gestire i backup di codice compilabile che potrebbe effettivamente tornare al sistema di controllo della versione.
In entrambi i casi costringendo uno sviluppatore per aspettare per il check-in codice è un disastro imminente del codice perso a un certo punto.
Garantire che il codice non rimane interrotto per troppo tempo è il lavoro di continuous integration, non il controllo di versione.
e anche se la tua azienda non crede in CI puoi metterla su una delle tue macchine (è solo una guerra in JEE e non ti rallenterà). – IAdapter
Se la vostra azienda ha un controllo abbastanza strano da richiedere che il trunk sia sempre compilato, CI dovrebbe essere il loro sogno bagnato ... impone che il trunk possa compilare * e * il colpevole in pochi minuti ... –
Penso che la domanda riguardi l'impostazione della politica (ad es. non commetterai cambiamenti di rottura "), non sul rafforzamento tecnico di quella politica. –
In aggiunta ai commenti di Brian e Aaron, vorrei solo aggiungere che anche questo compromesso tra stabilità e codice aggiornato può essere mitigato utilizzando le filiali o, come soluzione più estrema, un sistema decentralizzato come Git. "Impegnarsi spesso e lasciare che il bot di compilazione trovi gli errori" è la mia politica preferita, ma se hai bisogno di un posto più stabile per controllare il codice, un ramo è quello che vuoi (ma ovviamente qualcuno deve mantenerlo).
Raccomando questa metodologia ai membri del mio team. Rimuove il timore di rompere la compilazione (dal momento che il ramo della funzione non viene in genere creato automaticamente) fornendo al contempo la sicurezza di avere le modifiche nel repository. Aiuta anche il mio team a imparare come unire meglio il loro codice, dal momento che li incoraggio a reintegrare i propri rami di funzionalità. – arcain
@arcain Si sta utilizzando la gestione integrata di unione di SVN? Quanto bene funziona? Te lo chiedo perché siamo stati bruciati da una caratteristica disordinata che si è fusa qualche mese fa, e siamo rimasti bloccati a selezionarlo a mano dato che stavamo girando una vecchia versione SVN. –
Usiamo TortoiseSVN e non ho mai avuto un errore flat-out di fusione con un errore, ma abbiamo riscontrato casi di errore dell'operatore da parte di un committer in cui un commit accidentale a un ramo ha richiesto un rollback di poche revisioni. Il reintegro automatico del ramo non era un'opzione in quanto l'intero intervallo di revisione non poteva essere unito al genitore, quindi abbiamo dovuto cherrypick gli intervalli di revisione. In alcuni di questi casi, era semplicemente più semplice ignorare il rev unito alla copia di lavoro dal ramo, contrassegnare i conflitti come risolti e unire manualmente le modifiche. – arcain
A mio parere, dipende dal tipo di VCS che viene utilizzato:
Dal momento che hai contrassegnato la tua domanda svn, seguire Aaron.
In base alla mia esperienza, è importante almeno provare per non commettere modifiche di interruzione. Più così se la squadra è più grande, o il ritmo di sviluppo è più veloce. L'idea è che tutti i membri del team siano aggiornati con le ultime modifiche. Nessuno dovrebbe aver paura di eseguire uno svn update dopo ogni commit da parte di un membro del team.
questo è impossibile se l'ultima versione ha regolarmente errori di compilazione. Anche un test negativo può essere fastidioso, perché non è sempre facile capire se un problema è stato introdotto dalle modifiche non salvate o da quelle appena ricevute dallo svn update. I lavori si fermano mentre tutti cercano di capire perché improvvisamente le cose non funzionano più.
rottura modifiche saranno anche interferire con la capacità di bisect the source code history. Quindi, anche se lavori da solo o su feature branch, può comunque essere prezioso per evitarli.
Una politica per evitare di rompere le modifiche non deve contraddire con regolari piccoli commit. Le grandi modifiche possono quasi sempre essere suddivise in un elenco di attività più piccole, ognuna delle quali può essere completata con un commit di dimensioni modeste che non interrompa la creazione.Questo ha il vantaggio aggiunto che i conflitti sono ridotti. Io tendo a mettere le cose come questa nel mio messaggi di commit per tali attività più piccole:
- verso fissaggio xyz: refactoring fuzz in preparazione dello aspetto foo
- verso fissaggio xyz: aspetto foo ora funziona
- fisso xyz: ba aspetto r ora lavora
+1. Sono d'accordo. Impegnati il più spesso possibile. Non pensarci sopra. Devi solo impegnarti il più possibile. Trovo che ci siano solo benefici e nessun inconveniente da commettere spesso. – Upgradingdave
+1. Sono d'accordo pure. Non vuoi che gli sviluppatori escano dallo sviluppo in una grotta, quindi lanciano una pila di bit e byte ad altri programmatori dicendo "Divertiti!" Ho lavorato in una società che aveva una politica se perdevi più di un giorno di valore o lavoro (virus, disco rigido si è schiantato, laptop rubato, ecc.), A seconda delle circostanze e di altri fattori, potrebbe essere un reato infuocato. – jgifford25
@ jgifford25 Eee-yikes !! Spero che tu sia stato ben ricompensato per quello stress ... Penso che sarei impazzito a preoccuparmi ... –