Come mantenere Subversion e un server remoto (via FTP) sincronizzati?

Question

Stiamo facendo fatica a mantenere Subversion e FTP in-sync. A volte ci dimentichiamo di commettere modifiche e basta inviarle al server web, abbiamo cartelle .svn sparse sul nostro server web, alcune cose esistono in un posto e non esistono nell'altro, ecc.

Voglio prendere il tempo di sistemare questo, oggi. Qual'è la soluzione? C'è un modo in cui SVN può essere collegato al nostro server web, in modo che possiamo impegnarci sia sul repository che sul server web via FTP? Dovremmo chiedere al nostro host web per qualche altro sistema che sarebbe meglio sincronizzare con il repository SVN? Come facciamo a far sì che il repository e il server web siano entrambi sincronizzati? Come rimuovere le cartelle .svn?

Proprio come dice il titolo, come possiamo mantenere sincronizzati il ​​nostro repository SVN e il nostro server web?

Answer 1

Quello che faccio sul mio server è che si tratti di un controllo del codice sul server.

Così, invece di usare ftp per spingere le cose al server, ho solo accedere ad esso ed eseguire una svn up. Procedendo manualmente in questo modo si ottengono numerosi vantaggi, inclusa la possibilità di eseguire il rollback in caso di codice buggato.

Mi consiglia anche l'uso di un sistema di migrazione db (supponendo che si stia utilizzando un database). Ciò ti consentirà di ripristinare facilmente le modifiche dello schema db per assicurarti che il codice continui a funzionare in caso di un rollback.

La combinazione di questi con un attrezzo simile a Fabric o Capistrano, darebbe un sistema di distribuzione molto robusto e potente.

Nota sui DVCS:

Alcune persone qui hanno parlato con un distributed vcs. Alcuni degli esempi più popolari di questi sono git e mercurial (ce ne sono molti altri).

Entrambi hanno uno schema di utilizzo diverso da svn, ma questo non si applica direttamente a questa domanda. Il più grande guadagno che si può avere è che se si fanno tag per ogni push al server live il costo di farlo è minuscolo rispetto al modello di tagging tradizionale per svn.

Se si volesse expirement con uno di questi GitHub e BitBucket entrambi offrono repository di hosting per, rispettivamente, git e mercurial gratuito.

Detto questo, sono un grande sostenitore dell'uso di un dvcs e la mia preferenza personale è mercurial.

Answer 2

Impostazione a post-commit hook che aggiorna l'FTP e utilizza esclusivamente SVN per le modifiche. In questo modo, quando vengono apportate modifiche, il tuo server web verrà aggiornato.

Questo presuppone che il server Web sia un server di gestione temporanea. Vedi i commenti per i dettagli.

Answer 3

Questo sembra un problema fatto su misura per un sistema di controllo di revisione distribuito.

Answer 4

Non si desidera eseguire il commit delle modifiche su un server Web in tempo reale senza alcuna forma di test, vero?

Risposta breve: eseguendo un nuovo checkout (preferibilmente su un server centrale) e copiando solo i bit necessari per eseguire l'app.

Si consiglia di impostare continous integration, dove il server di generazione è responsabile del recupero delle origini più recenti dal repository Subversion, esecuzione di una build e preparazione dei pacchetti di distribuzione per vari ambienti (test/staging) e potenzialmente FTP in corso alla confezione di produzione una volta soddisfatti delle modifiche apportate al test o all'ambiente di gestione temporanea.

Questo è l'unico solido modo per garantire che i cambiamenti DEVONO essere commessi (non lo so, ma sembra essere incerto nel tuo scenario) o altrimenti semplicemente non finiranno nella distribuzione. Applica il processo di buona gestione dei rilasci, per non dimenticare che puoi aggiungere ogni sorta di altre meravigliose cose di automazione al tuo server di build come test di unità e test funzionali.

Answer 5

Il modo migliore che ho trovato per fare questo è di garantire che nulla di non impegnato possa sfuggire al server - questa è una scappatoia che devi risolvere prima.

Quindi, impostare un checkout locale delle parti del repository che si desidera sincronizzare e utilizzare rsync per inviare i dati al server (FTP non è molto utile in questo contesto). rsync ti consente di escludere file e directory, quindi usa questa funzione per assicurarti che le directory .svn non vengano sincronizzate.

Answer 6

Prima di implementare in seguito, è consigliabile utilizzare un ambiente di test in cui è possibile eseguire l'FTP direttamente, quindi eseguire il push dal vivo, eseguire il commit di tale versione di file e consentire l'esecuzione di questa attività.

Da tigris:

Questo viene fatto per tutto il tempo, ed è facilmente realizzabile con l'aggiunta di un-commit Post Script gancio al repository. Leggi informazioni sugli script di aggancio nel capitolo 5 del libro. L'idea di base è di rendere il "sito live" solo una copia di lavoro ordinaria, e quindi il tuo script di hook post-commit esegue "svn update" su di esso.

In pratica, ci sono un paio di cose a cui fare attenzione. Il programma server che esegue il commit (svnserve o apache) è lo stesso programma che eseguirà lo script di hook post-commit. Ciò significa che questo programma deve disporre delle autorizzazioni appropriate per aggiornare la copia di lavoro. In altre parole, la copia di lavoro deve essere di proprietà dello stesso utente che svnserve o apache esegue come - o almeno la copia di lavoro deve avere le autorizzazioni appropriate impostate.

Se il server deve aggiornare una copia di lavoro che non è proprietario (ad esempio, l'utente di Joe ~/public_html/zona), una tecnica è creare programma binario a + s per eseguire l'aggiornamento, dal momento che Unix ha vinto' t consentire agli script di eseguire + s. Compilare un programma C minuscola:

#include <stddef.h> 
#include <stdlib.h> 
#include <unistd.h> 
int main(void) 
{ 
    execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/", 
    (const char *) NULL); 
    return(EXIT_FAILURE); 
} 

... e poi chmod + s binario, e assicurarsi che sia di proprietà dell'utente 'Joe'. Quindi nel hook post-commit, aggiungi una linea per eseguire il binario.

In caso di problemi durante il funzionamento, consultare "Perché i ganci del repository non funzionano?".

Inoltre, probabilmente vorrai impedire ad apache di esportare le directory .svn/nella copia di lavoro live. Aggiungi questo al tuo httpd.conf:

# Disallow browsing of Subversion working copy administrative dirs. 
<DirectoryMatch "^/.*/\.svn/"> 
    Order deny,allow 
    Deny from all 
</DirectoryMatch> 

Answer 7

Springloops fa esattamente ciò che si richiede. Provaci. È SVN combinato con FTP. Si lavora sulla copia di lavoro locale, quindi si inviano le modifiche al repository, quindi tramite Springloops si distribuisce la revisione selezionata su qualsiasi server (gestione temporanea o produzione) tramite FTP.

Answer 8

Stavo per suggerire Springloops quando ho fatto scorrere verso il basso e ho visto il suggerimento di Chris. Sto usando SpringLoops negli ultimi due mesi e lo adoro assolutamente.

È possibile impostare i dettagli FTP per i server di gestione temporanea e di produzione per ciascun repository. Quindi è possibile pubblicare su tali server tramite FTP, specificando il numero di revisione da distribuire.

Qualcosa che mi piace davvero di questo è che posso vedere a quale versione ogni server è tramite la pagina di distribuzione in Springloops. E con tutto ciò che viene distribuito tramite Springloops, sai che questo è accurato.

In realtà ho cercato una soluzione che è un po 'più di un semplice repository SVN .. qualcosa con ticketing integrato, wiki e cronometraggio. Mi piace molto Bitbucket, ma non ha la funzione di distribuzione FTP di Springloops, che purtroppo lo esclude. Per ora rimarrò con Springloops fino a quando un altro servizio non sarà in grado di offrire la distribuzione FTP.

Perché la distribuzione FTP è così importante per me sento delle persone che borbottano sottovoce .. ti dirò volentieri: mi schiererò su vari server diversi. Alcuni sono scatole dedicate, alcune macchine virtuali ospitate sul cloud e alcuni hosting condiviso. Non desidero mantenere una metodologia di distribuzione separata per ciascuno, quindi il metodo di implementazione comune a tutti è FTP. Springloops si trova davvero bene tra il mio codice sorgente e i miei server. Ecco perché :)

Answer 9

Prova http://svn2ftp.com - nessuno del volume di gestione del progetto, puoi semplicemente configurare repository SVN che si sincronizzeranno automaticamente con qualsiasi numero di account S/FTP su ciascun commit.

Answer 10

Questo sito mostra come configurare Subversion per fare esattamente quello che stai cercando. http://www.itforeveryone.co.uk/svn2web.html