Modifica sul posto, controllo della versione: qual è la tua soluzione?

Question

Sto usando SVN per le attività di sviluppo, ma ho ancora molti file gestiti con RCS, perché non sembra ragionevole modificarli nella mia copia di lavoro del repository SVN privato (poiché spesso sono solo file di configurazione che sono anche meglio testati a posto). Inoltre non sembra ragionevole avere una copia funzionante del repository ovunque ci siano file da mettere sotto il controllo SVN, quindi uso RCS invece.

Qual è il tuo approccio per la gestione di file che idealmente non dovrebbero essere spostati / modificati e testati sul posto?

Per essere più precisi: mi piacerebbe avere l'equivalente di

• con un file.txt protetto da scrittura
• un comando come " co -l file.txt " (RCS) per renderlo modificabile
• la possibilità di modificarlo sul posto e testarlo immediatamente
• un comando come " ci -u file.txt " (RCS) per registrare la modifica, aggiungere un commento e renderlo di sola lettura
• anche altri utenti dovrebbero poterlo fare nello stesso posto
• ma, le informazioni sulla versione dovrebbero andare in un posto sicuro (presumibilmente svn rep), su un server diverso

Answer 1

Uso copia su file system di scrittura (CoW) come Ext3cow (dichiarazione di non responsabilità, sono uno dei suoi collaboratori ) per gestire molte cose. Ad esempio:

• Utilizzo di snapshot per ripristinare interi repository, indipendentemente dal tipo. Ad esempio, se rovino completamente un git tree, posso cp -dpfR ./@123456789 ./, che sostituisce il mio repository funzionante con i file così come erano all'epoca 123456789.
• Utilizzo di versioning / snapshot come proprio VCS immutabile, ideale per / etc e altre cose. Poiché i file in passato non possono essere eliminati o modificati, ogni istantanea è una revisione immutabile di un singolo file o dell'intero albero nel tempo.

In genere, utilizzo Git o Mercurial su Subversion perché preferisco un VCS distribuito, ma ora insisto per mantenere i miei repository su un FS di versioning localmente.

Per gli utenti Windows, credo che ci siano alcune implementazioni portatili dello stesso eseguite completamente in Python ... ma non sono sicuro.

Answer 2

Come detto prima, stai tentando di usare SVN per qualcosa che dovrebbe usare un DVCS come git o Mercurial.

Ognuno può avere il proprio repository e quindi sincronizzarlo con il repository centrale mais (come il repository SVN).

Questo è in realtà quello che uso nei miei progetti.

L'unica cosa che non ho capito è perché hai bisogno di lucchetti. Un file non deve essere di sola lettura. Probabilmente stai pensando in quel modo a causa del modo in cui SVN si fonde (devi quasi sempre farlo a mano). Git fa davvero magia [1] e la maggior parte delle fusioni è priva di intervento umano.

[1] Ok, non è magico. Mentre a SVN importa dei file, a Git importa dei blocchi di codice. In questo modo può unire un file modificato due volte contemporaneamente, purché non modifichi esattamente la stessa porzione di codice.

Answer 3

I moderni sistemi di controllo della versione distribuita come Git, Mercurial o Bazaar sono lo strumento migliore in una situazione come questa. Non a causa dell'aspetto distribuito (che qui non è chiaramente cruciale), ma perché è estremamente facile creare un repository sul posto.

In Mercurial devi solo fare:

cd ~/directory
hg init

Con Git è simile:

cd ~/directory
git init
git add .

Ogni copia di lavoro è un repository completo e puoi inviarlo al server remoto come backup, se lo desideri. Inoltre, tutti i dati del repository sono archiviati in una singola directory nascosta, in modo da evitare il problema di avere tonnellate di directory .svn in tutto il luogo.

Uso Mercurial per gestire / etc sui miei server e lo trovo estremamente conveniente. Una cosa da notare, non segnerà il tuo file in sola lettura (come RCS), ma lo considero un vantaggio.

Answer 4

È necessario rendersi conto che i repository SVN sono gratuiti. Puoi crearne quanti ne vuoi.

È inoltre necessario rendersi conto che non è necessario controllare un intero repository. Hai detto:

  

Inoltre, non sembra ragionevole   avere una copia funzionante del repository   ovunque ci siano file da mettere sotto   Controllo SVN

Non sono sicuro di quello che stai davvero cercando di fare, ma ho l'impressione che usi SVN in un modo particolare.