Come posso diramare un singolo file in SVN?

Question

Il concetto di sovversione della ramificazione sembra focalizzato sulla creazione di un fork [non] stabile dell'intero repository su cui effettuare lo sviluppo. Esiste un meccanismo per la creazione di rami di singoli file?

Per un caso d'uso, pensa a un file di intestazione comune (* .h) con più implementazioni di origine specifiche della piattaforma (* .c). Questo tipo di ramo è permanente. Tutte queste filiali vedrebbero uno sviluppo continuo con occasionali fusioni tra filiali. Ciò è in netto contrasto con lo sviluppo instabile / i rami a rilascio stabile che generalmente hanno una durata limitata.

Non non desidero ramificare l'intero repository (economico o meno) in quanto creerebbe una quantità irragionevole di manutenzione da unire continuamente tra il tronco e tutti i rami. Al momento sto usando ClearCase, che ha un diverso concetto di ramificazione che lo rende facile. Mi è stato chiesto di prendere in considerazione il passaggio a SVN, ma questa differenza di paradigma è importante. Sono molto più preoccupato di poter creare facilmente versioni alternative per singoli file che di cose come tagliare un ramo di rilascio stabile.

Answer 1

Purtroppo, penso che la vera risposta qui sia che ClearCase gestisca questa situazione molto meglio di Subversion. Con sovversione, devi ramificare tutto , ma ClearCase consente una sorta di "ramo pigro" idea che significa che solo un determinato gruppo di file è ramificato, il resto di loro segue ancora il trunk (o qualunque ramo specificato).

Le altre soluzioni fornite qui non funzionano davvero come previsto, stanno solo copiando il file in un percorso diverso. Ora devi fare cose strane per usare effettivamente quel file.

Ehm, scusa. Non è stata davvero un'ottima risposta. Ma non c'è una buona soluzione a questo con Subversion. Il suo modello è branch and merge.

Modifica: OK, quindi espandendo ciò che ha detto crashmstr. Puoi farlo:

svn cp $REP/trunk/file.h $REP/branched_files/file.h
svn co $REP/trunk
svn switch $REP/branched_files/file.h file.h

Ma wow !, è soggetto a errori. Ogni volta che fai una svn vedrai questo:

svn st
    S  file.h

Un po 'rumoroso. E quando vuoi ramificare alcuni file o moduli all'interno di un repository di grandi dimensioni, inizierà a diventare molto confuso.

In realtà, probabilmente qui c'è un progetto decente per simulare qualcosa come i file ramificati di ClearCase con proprietà svn e cambio, scrivendo un wrapper attorno al client svn standard di bog per gestire tutto il casino.

Answer 2

Non è necessario ramificare l'intero repository. È possibile creare rami di cartelle nel progetto (come una cartella di inclusione). Come altri hanno già notato, puoi anche fare una copia di " di un solo file. Una volta che hai una copia di un file o di una cartella, " cambia " al file o alla cartella ramificati per funzionare sulla versione del ramo.

Se si crea una cartella di rami separata nel repository, è possibile copiare i file ramificati lì tramite i comandi sul lato server:

svn copy svn://server/project/header.h svn://server/branched_files/header.h

Quindi puoi cambiare quel file per usare il percorso del repository branch_files

Answer 3

Ecco come capisco il tuo problema. Hai il seguente albero:

time.h
time.c

e devi rifiutarlo per più architetture:

time.h is comon
time.c (for x386), time.c (for ia64), time.c (for alpha),...

Anche nell'attuale VCS puoi farlo creando tutti i rami da time.c necessari e quando esegui il checkout dei file dal VCS, controlli automaticamente l'ultima ora.h dal trunk comune e l'ultima ora.c dal ramo su cui stai lavorando.

Il problema di cui ti preoccupi è che se usi SVN durante il check out di un ramo dovrai unire molto spesso time.h dal trunk o rischiare di lavorare su un file più vecchio (rispetto al trunk) con quel sovraccarico non è accettabile per te.

A seconda della struttura del codice sorgente, potrebbe tuttavia esserci una soluzione. immagina di averlo

 
/
/headers/
/headers/test.h
/source/
/source/test.c

Quindi puoi ramificare / e utilizzare svn: externals funzione per collegare le intestazioni alla testa del bagagliaio. Funziona solo su directory e presenta alcune limitazioni per quanto riguarda il commit di nuovo su test.h (devi andare nella directory header per farlo funzionare) ma potrebbe funzionare.

Answer 4

A Subversion " branch " è solo una copia di qualcosa nel tuo repository. Quindi se vuoi ramificare un file, dovresti semplicemente:

svn copy myfile.c myfile_branch.c

Answer 5

Non penso che abbia molto senso ramificare un singolo file? Non c'è modo di testarlo con il codice trunk?

Potresti invece prendere una patch se desideri annullare le modifiche e applicarle in seguito.

Answer 6

Sei sicuro di aver davvero bisogno di questa funzione nel tuo VCS ?

Perché non utilizzare il preprocessore C e #ifdef per eliminare il codice non necessario? O qualsiasi strumento simile.

qualcosa del tipo:

// foo.h:
void Foo();

// foo_win32.c
#ifdef _WIN32
void Foo()
{
   ...
}
#endif

// foo_linux.c
#ifdef _GNUC
void Foo()
{
   ...
}
#endif

A volte se non va bene, allora non è la soluzione giusta.

Answer 7

Un ramo in SVN è solo una copia. Credo che per farlo nel modo in cui speri, dovresti avere ogni versione del file in una directory separata nel repository e verificarlo nella cartella di origine. OSSIA tratta quel file come un progetto separato.

Answer 8

Un ramo in Subversion è esattamente ciò di cui stai parlando. Tutti i file sono una copia esatta del trunk, ad eccezione di quelli modificati. Questa è la "copia economica" metodologia di cui si parla nel libro SVN. L'unica avvertenza è la necessità di unire il tronco nel ramo di volta in volta per assicurare che le modifiche apportate si riflettano nel ramo. Ovviamente, se questi cambiamenti non sono desiderati, non è necessario che si verifichino fusioni di rami.

Un modo semplice per consentire l'unione automatica delle modifiche del trunk (che simula il paradigma Clear Case) sarebbe utilizzare uno script hook pre-commit per unire le modifiche del trunk prima del commit. (In effetti, questo è sempre una buona strategia per prevenire la deriva del codice).