best practice per la memorizzazione di file non di origine sotto controllo di versione

Question

Ho un progetto sotto controllo di versione, ma il progetto ha alcune immagini, video e file zip che cambiano ogni tanto. Non voglio memorizzare questi file sotto controllo di versione perché occupano molto spazio e apportano aggiornamenti e commit molto lenti.

Qual è un buon modo per gestire questo problema e salvare ancora i file non di origine che sono stati modificati? C'è un modo migliore?

Attualmente sto usando subversion, se c'è un altro client di controllo versione che è migliore per affrontare questo problema, per favore raccomandalo!

Answer 1

Hai aggiunto in un commento:

Il problema che ho con questo è che non mi interessa la storia versione di quei file zip/video, fintanto che sono quelli più recenti, non c'è problema.

Ciò significa che si dispone di un flusso di lavoro lineare di sviluppo, che funziona solo nell'ULTIMO di un ramo principale.
Non sembri a che fare con la fase "dopo il rilascio", dove si deve:

• mantenere ciò che viene eseguito in produzione
• sviluppare piccole evoluzioni ...
• ..mentre facendo massiccia refactoring per sperimentare alcuni grandi evoluzioni

Negli ultimi tre casi, la questione del "quali sono state le esatte immagini, video e file zip 'devo usare' o 'stavo usando al momento' potrebbe b È importante.

In ogni caso, se ritieni che SVN non li gestisca in modo appropriato, ti consiglio comunque di avere un modo per ricordare che, per la revisione SVN da xxx a yyy, stavi usando la versione 'z' del tuo set di binari.
Per questo, è possibile configurare un repository esterno come Maven. Vedi domanda "Is it acceptable/good to store binaries in SVN?" (la mia risposta in questa domanda è vicino alla parte superiore della pagina, ma collego direttamente alla risposta di Evan quando menziona Maven).

Answer 2

Ho molti file non di origine in SVN e l'unica volta che rallenta il commit è quando li cambio. Non vedo come questo sia un problema se cambiano "ogni tanto". Anche la dimensione non dovrebbe essere una preoccupazione. Se il tuo repository si trova su un server e sei preoccupato di quanto spazio occupi devi aggiornare. I dischi rigidi sono economici. Comprali.

Alcuni ritengono fortemente che i file non di origine non appartengano al controllo del codice sorgente, dico che un intero progetto deve essere archiviato nel controllo del codice sorgente. In questo modo, se il mio sistema di sviluppo si interrompe, posso passare a un altro e dopo un paio di minuti di download del progetto sono tornato a programmare.

Answer 3

Mentre trovo un enorme problema affrontare i file non di testo nel controllo di versione, specialmente quelli che cambiano molto, ho accettato la pratica di "se è necessario per la build/installer che dovrebbe andare in controllo della versione ". Questo ovviamente non è una regola difficile. Non mantengo le librerie di terze parti sotto controllo di versione (anche se conosco le persone che lo fanno).

Sono rientrato in questa opinione dopo aver configurato un server di Continuous Integration nel mio negozio. Rendere tutto ciò che è necessario per la build che potrebbe cambiare lo rende molto più semplice. Come accennato in precedenza, non mantengo le librerie sotto controllo di versione, ma ciò è dovuto al fatto che raramente aggiorniamo/aggiungiamo nuove librerie. Se questo non è il caso per il tuo negozio, puoi prendere in considerazione di farlo. Inoltre, se le tue immagini/video/zip cambiano più di una volta all'anno, ti consiglio di tenerle sotto controllo di versione.