2009-09-04 16 views
10

Ho una directory su un sistema Linux che contiene principalmente collegamenti simbolici a file su un altro filesystem. Vorrei aggiungere la directory ad un repository Subversion, dereferendo i collegamenti simbolici nel processo (trattandoli come i file a cui puntano, piuttosto che i collegamenti). In generale, mi piacerebbe essere in grado di gestire qualsiasi operazione di copia di lavoro con questo comportamento, ma il comando "svn add" è dove inizia, penso.Il client Subversion (svn) può derefare collegamenti simbolici come se fossero file?

L'utilità del client SVN non sembra avere alcuna opzione relativa al dereferenziamento dei collegamenti simbolici nella copia di lavoro. Non ho trovato alcun riferimento a questo nel manuale (http://svnbook.red-bean.com/en/1.5/index.html).

ho trovato un poster sugli utenti SVN lista che ha chiesto la stessa domanda, ma non ha mai ricevuto una risposta, qui mailing:

(quel poster finito per usare hard link, invece di Questa tecnica non è un'opzione, nel mio caso, perché i veri file sottostanti risiedono su un filesystem separato.)

Sto usando Subversion v1.6.1 su Fedora 11.

Per quello che vale, so che ci sono strumenti/tecniche alternativi che potrebbero aiutare ad approssimare questo comportamento, ma che devo scartare per vari motivi. Ho già considerato [e trattato con la polvere] queste possibilità: - una montatura "union", unendo tutte le directory contenenti i file reali, con la directory di copia di lavoro SVN come il livello "top" nell'unione; - copia/sposta i file reali sullo stesso filesystem della copia di lavoro SVN e utilizza i collegamenti fisici anziché i collegamenti simbolici; - Sistemi di controllo versione non SVN. Queste erano tutte idee chiare, e sono sicuro che sono buone soluzioni ad altri problemi, ma non funzionerebbero visti i vincoli di questo ambiente e situazione.

+0

Non credo sia possibile (e non penso che nessun VCS possa farlo, segue i collegamenti simbolici ma non li tiene traccia o li segue e non segue). – tonfa

+0

Inizia a sembrare così. Il che sembra stupido, dato che la maggior parte delle utility che manipolano i costrutti del percorso (cp, mv, ln, rm, rsync) hanno tutte le opzioni per specificare che i collegamenti simbolici dovrebbero essere dereferenziati, non trattati alla lettera. Voglio dire, sono solo io o l'assenza di un'opzione "dereferenziazione" diminuisce la funzionalità dello strumento? (Se sono solo, qui, probabilmente non mi preoccuperò di inviare una richiesta di funzionalità al progetto SVN.) –

+0

3 anni di ritardo, ma non sei solo. Anch'io ho bisogno di questo. –

risposta

1

Hai molti vincoli, ma c'è una cosa che funziona sempre: hackerare la fonte.

Si può facilmente creare il proprio svn per linux, anche se rendere questo mod può essere o meno "facile". Ad ogni modo, se non hai link simbolici gestiti, puoi fare un rozzo trucco e avere semplicemente svn seguirli sempre, come se fossero collegamenti duri.

Se il repository contiene collegamenti con versione e è necessario verificarne la parte, è necessario un trucco più sofisticato che, ad esempio, utilizza una proprietà che controlla la funzionalità per file o per gerarchia o qualcosa del genere.

Potrebbe esserci un'altra scelta: i collegamenti con versione sono apparsi in 1.1.0, se il comportamento precedente era quello di seguire collegamenti simbolici allora forse si poteva semplicemente eseguire un vecchio client.

+0

Quindi stai dicendo che la risposta alla mia domanda reale (può farlo il client SVN) è "no". Destra? –

+1

Giusto, sto dicendo "no, almeno, non dalla versione 1.1.0 e forse non prima, neanche". Suppongo che tu abbia preso in considerazione l'aggiunta degli altri alberi del filesystem e quindi solo il mantenimento di symlink locali non verificati. Sembrerebbe funzionare bene tranne che per richiedere più di un commit o di un aggiornamento per sincronizzare l'intera copia di lavoro. (Ma non su altre copie funzionanti senza i collegamenti locali.) – DigitalRoss

0

Idea: iniettare una libreria condivisa utilizzando LD_PRELOAD che intercetta stat/open/unlink ecc. In modo che svn non veda i collegamenti simbolici. Ciò ti eviterà di dover modificare la sorgente svn.

0

È anche possibile utilizzare collegamenti fisici anziché collegamenti simbolici.

0

Per quanto ne so, con la versione di sovversione corrente (1.6.x) non c'è modo di farlo. Se fosse stato per i file (non le directory) sullo stesso file system, avresti potuto utilizzare i collegamenti fisici (senza lo switch -s nel comando ln).

0

Ho affrontato una sfida simile. La mia home directory contiene molti script in ~/scripts sparsi su varie sottodirectory. Tuttavia, volevo un layout più pulito in SVN per avvantaggiare i colleghi che esaminano le cose alla ricerca di esempi di codice.

ho creato una directory ~/scripts/svn/signal15/code/ con prod e test sub-directory sotto, poi duri-linked tutti gli script sparse altrove.

Il seguente comando ha quindi importato il layout di directory/file necessario;

cd ~/scripts ; svn import svn http://svn_server/repos/code

Il pronti contro termine mostra ora http://svn_server/repos/code/signal15/ con "prod" e "test" sub-directory.

Ora ho layout personalizzati; a) Il layout della mia directory home rimane invariato (sottodirectory ~/scripts/svn) b) Il repository SVN contiene un ramo "signal15" con i miei script organizzati. P.S: con una funzione shell, posso anche effettuare il check-in e il check-out.

Problemi correlati