Sicuro per condividere una copia di lavoro di Subversion tra SO?

Question

Ho sentito dire in passato che è pericoloso condividere una copia di lavoro di Subversion tra il sistema operativo.

Es .:

1. copia di una copia di lavoro da una macchina Windows a una macchina Linux, e utilizzare la build per Linux di SVN su di esso.
2. Su un computer Windows, accedere/manipolare una copia di lavoro SVN con entrambi i file binari di Windows e i file binari CygWin di SVN. (Potrei voler fare questo per usare this solution per esempio).

Ma non ho sentito in modo definitivo se potrebbe causare il danneggiamento dei dati .svn. È vero che i problemi EOL potrebbero essere un problema se svn: stile eol è impostato su nativo.

Qual è lo stato corrente di questo problema? È cambiato nelle versioni più recenti di SVN? È sicuro a condizione che vengano prese alcune precauzioni (ad esempio non controllare/aggiornare i file con svn: eol-style = nativo su entrambe le piattaforme)?

Answer 1

Ho usato svn su una directory di rete condivisa tra unix, linux, solaris e windows; aneddoticamente, l'unico problema che ho incontrato è che le diverse versioni del client svn sono "incomplete". Le macchine linux e unix erano dotate di una versione di svn più vecchia di quella di solaris svn; che a sua volta era più vecchio del client della macchina Windows. Il risultato è che l'esecuzione di 'svn up' aggiorna i file di metadati su qualunque client sia in esecuzione; e il client non accederà ai file con una versione più recente dei metadati. Il risultato finale è che i client svn devono essere mantenuti allo stesso numero di versione.

Quindi, sì, sono stato in grado di spostare una directory di lavoro tra macchine con perdite minime di vita. Detto questo, non ho mai usato nessuna opzione svn oltre a quella predefinita.

Answer 2

Il mio repository svn è su Linux. Ho una copia funzionante su Linux e un'altra su WindowXP.

Su WindowXP, utilizzo cygwin per accedere alla mia copia di lavoro. A volte, uso anche Tortoise per avere una differenza visiva, una cronologia completa di un file ...

Non provo mai a ripristinare (o creare un modulo di backup) da un repository Linux creato con svndump su un computer Windows.

[EDIT]

ho dimenticato di dire che l'aggiornamento funziona perfettamente sia con copia di lavoro.

Answer 3

Dalla mia esperienza, funziona.

Tuttavia, a volte esistono problemi relativi alla distinzione tra maiuscole e minuscole tra Windows e Linux. Cartelle "Build" e "build" colliding e cose come ".htaccess". Ma niente di difficile da risolvere.

Answer 4

Come già detto CoderTao, l'uso di diverse versioni di svn (client) su una copia funzionante può causare aggiornamenti di formato WC inattivi, quindi assicuratevi di rimanere all'interno di una singola famiglia di versioni per evitarlo.

Come una parte della tua domanda principale, vedo che stai lavorando con un repository SVN su un collegamento lento. Si consiglia di esaminare i sistemi di controllo del codice sorgente distribuiti che sono progettati per quel genere di cose.

Ad esempio, Bazaar (bazaar-vcs.org) ha un plugin bzr-svn che consente di creare un ramo locale di un repository SVN remoto. Quindi disponi di una succursale locale veloce che puoi verificare in più sedi, lavorare localmente, diff, sfogliare la cronologia, ecc. Puoi effettuare il commit localmente e mantenere sincronizzati i tuoi rami locali (Giappone) separati senza lenta commit in Australia. Una volta che tutto è a posto, devi trasferire le modifiche a monte di SVN. Se sei interessato, ci sono molti documenti di esempio sul flusso di lavoro sul wiki di Bazaar. :)

Answer 5

Altre risposte a parte (come sembrano suggerire che sia fattibile), posso segnalare categoricamente che condividere una copia funzionante (nel nostro caso tramite una condivisione Samba) in cui abbiamo avuto "svn: eol-style nativo" in utilizzare ha fatto causare problemi per noi, e cerchiamo di evitarlo.

Se dovessimo copiare una cartella di lavoro tra macchine (una forma più limitata di condivisione, presumibilmente come un'operazione singola) ci aspetteremmo di dover entrare ed eseguire conversioni CRLFTOLF su tutto lo stile svn: eol file, e in effetti lo abbiamo fatto in passato scrivendo un'utilità per camminare sull'albero, esaminando le proprietà svn e convertendo i file come richiesto (tutto in Python).

Quindi per la cronaca, dichiaro definitivamente che questo è un problema.