Come utilizzare Subversion Repository all'interno del repository Git?

Non posso essere l'unico a pensare agli Xzibit elementi annidati meme , giusto? Comunque ...

Una delle cose interessanti che Subversion fa è chiamata "esterni". È un modo per indicare un ramo o una directory specifici in un altro repository svn. Puoi persino collegarlo a una versione specifica di una directory specifica. Gli esterni sono davvero dannosi e risolvono questo problema in un istante, in quanto le modifiche apportate in una directory esterna vengono automaticamente reindirizzate alla fonte quando si esegue un commit.

Externals è anche qualcosa di mancante in git. Git ha sottomoduli , ma non funzionano nello stesso modo, in quanto sono legati a uno specifico commettere. Ciò significa in effetti che non esiste una soluzione nativa al problema di avere repository "nidificati" che possono essere letti e scritti allo stesso tempo e che rimangono perfettamente sincronizzati, non meno repository nidificati che utilizzano backend diversi.

Se non vuoi eseguire la revisione del sottomodulo ballare , c'è un'altra soluzione.

Git ha un'emulazione svn decente nello strumento git-svn . Probabilmente lo stai già usando. La domanda SO "Come mantenere un svn: esterno aggiornato usando git-svn? " ci offre un'opzione utile abusando di quello strumento.

La risposta accettata era semplicemente usando git-svn per controllare il repository Subversion al di fuori dell'albero controllato da git , semplicemente usando un link simbolico per puntarlo all'interno dell'albero. C'è un po 'più di lavoro manuale coinvolto in questo, poiché è necessario ricordare di memorizzare quel repository specifico ogni volta che si apportano modifiche in esso. Tuttavia, è semplice, è semplice ed è noto che funzioni.

Un'altra opzione interamente potrebbe riguardare i subrepository di Mercurial, che possono ospitare sia git che svn. Non sono sicuro se vuoi davvero andare su tre livelli.

Sebbene scoraggiato da Charles , penso che tu cerchi in cerca di git sottomoduli :

Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules.

Mentre Charles sembra ritenere che git sottomoduli siano carenti perché non possono funzionare come svn esterni (facendo riferimento alla testa di un ramo piuttosto che a un revisione specifica), penso che questo sia dovuto alla differenza nel flusso di lavoro previsto tra git e svn come qualsiasi altra cosa.

A seconda di quando e dove hai aggiornato la tua copia di lavoro, le directory in diversi punti nella tua svn gerarchia delle directory di lavoro potrebbero essere a revisioni diverse. Questo non è possibile con git . In git ogni volta che si aggiorna a una revisione, si aggiorna l'intera copia di lavoro a quella revisione - ci si aspetta che quando si passa alla revisione 123abc si ottenga lo stesso identico codice dell'ultima volta che si è verificato 123abc, e ciò include tutti i sottomoduli che la revisione potrebbe avere.

Se vuoi aggiornare un sottomodulo , devi aggiornarlo e quindi fare un nuovo commit al super-modulo per aggiornarlo per usare la nuova revisione nel sottomodulo . Significa che i sottomoduli sono meno flessibili di esterni , ma impone il paradigma git primario di un'istantanea ampia del repository.

Se vuoi che svn esterni utilizzi sempre la funzionalità di revisione più recente, sei praticamente da solo. Come già detto, devi solo controllare il svn submodule manualmente e poi .gitignore it.

• Dato il funzionamento di svn , il modo in cui esterni funziona è perfettamente accettabile.
• Dato il funzionamento di git , il modo in cui i sottomoduli funzionano è perfettamente accettabile.

Per inciso, per quanto ho capito, Mercurial subrepository funziona allo stesso modo dei sottomoduli di Git , quindi non sarà di alcun aiuto.

Stai solo cercando git-svn ? Con dipendi vuoi dire che la versione genitrice è in svn, o ha venditori che sono progetti svn?

Assumendo per dipendenze si intende dipendenza:

Puoi inserire qualsiasi tipo di repository all'interno di un repository git senza problemi. per es.

$ mkdir ~/project
$ cd ~/project
$ git init
$ ...
$ git commit -va
[master (root-commit) xxxxxxx] Did something
 ...
$ mkdir vendors
$ cd vendors
$ svn checkout svnproject(url)
$ cd svnproject
$ ...
$ svn ci -m "committing to svnproject"

ecc.

Quindi gestisci svnproject come faresti normalmente. Ovviamente puoi usare git-svn invece di interagire con il tuo repository SVN usando i comandi git.

Puoi anche fare questo:

$ cd ~/projects
$ git add vendors/svnproject
$ git commit -m "adding svnproject source to main repo"

In questo caso, gli aggiornamenti apportati ai file in svnproject verranno visualizzati sia come svn che come diff. Un esempio in cui /tmp/gitproject è un progetto .. git e /tmp/gitproject/vendor/minify è un checkout svn (casuale):

[andy@laptop:/tmp/gitproject/vendor/minify]$ vim README.txt 
[andy@laptop:/tmp/gitproject/vendor/minify]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working     directory)
#
#   modified:   README.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
[andy@laptop:/tmp/so/vendor/minify]$ svn status
M       README.txt
[andy@laptop:/tmp/so/vendor/minify]$

Se si utilizza git-svn per interagire con il repository svn-dipendente, è possibile mantenerlo sincronizzato con le modifiche apportate nel progetto git padre utilizzando git-filter-branch e quindi non è necessario eseguire il commit su ogni repository singolarmente .

Per inciso: dall'esperienza mantenere un progetto git e svn in sincrono è in genere piuttosto problematico a meno che uno o l'altro sia di sola lettura.