Newsgroup: it.comp.os.linux.sys
Titolo: Re: Backup o repository?

 Che consigli mi potete dare in merito?
git + rsync
ciao ...
-- 
Never try to teach a pig to sing.
It wastes your time and annoys the pig.

 Che consigli mi potete dare in merito?
Il Backup ed il Versioning non sono la stessa cosa e non dovrebbero
essere confuse. Per il backup, rsync o un banale tar.gz + scp, per il
versioning, vai di Subversion.
Davide
-- 
Politics is the art of looking for trouble, finding it everywhere,
diagnosing
it incorrectly, and applying the wrong remedies.
-- Julius Henry "Groucho" Marx (
http://en.wikiquote.org/wiki/Groucho_Marx
)

 E' una versione modificata di svn?
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Trovi comparazione di features e se segui i vari links vedi anche le 
peculiaritï¿œ delle singole soluzioni.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 versioning, vai di Subversion.
Interessa anche a me il versioning ma non ho mai
capito come funziona.
Qualche howto o tutorial che spiegano in generale come
funzionano tali sistemi ci sono in giro per la rete?

 funzionano tali sistemi ci sono in giro per la rete?
http://en.wikipedia.org/wiki/Revision_control
http://svnbook.red-bean.com/

 
http://svnbook.red-bean.com/
Si, lo conosco, ho la versione cartacea stampata
dal PDF scaricabile dal sito.
Per�, faccio un esempio:
supponiamo di avere un progetto in PHP.
Utente1 lavora su di esso e modifica determinati file
tra cui "ciccio.php"
Utente2 lavora sullo stesso progetto, modifica altri
file, ma anche "ciccio.php".
In tal caso, le due modifiche, come si fanno a gestire?
In che modo si pu� garantire che le modifiche di Utente1
non vadano a collidere con quelle di utente2 una volta
fatto il commit?
E se esistessero, per dire, due funzioni con lo stesso nome,
il programma di gestione versione, come si comporterebbe?
Tiene la versione di utente1 o quella di utente2?
Inoltre, se tengo la versione di utente1, alcune cose fatte
da utente2 potrebbero non funzionare dato che la funzione
potrebbe essere diversa e non compatibile...
Spero di aver reso, grossolanamente, l'idea..

 il programma di gestione versione, come si comporterebbe?
Se esistessero due funzioni distinte con lo stesso nome
si avrebbe un problema di software managemente e non di
revision control.
In altri termini, si deve sapere a monte che due persone
non andranno a creare conflitti di namespace.
bye,
-- 
piergiorgio

 potrebbe essere diversa e non compatibile...
Nella pagina di wikipedia c'e' un bel paragrafo "version merging"...e nel
libro ce n'e' un altro qui
http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.basic.vsn-models

 Che consigli mi potete dare in merito?
Per i VCS, se sei all'inizio usa Git o Mercurial, in quanto i sistemi
di controllo di versione distribuiti si stanno rivelando sempre piu`
comodi rispetto ai tradizionali sistemi client/server. Se proprio non
puoi farne a meno, usa Subversion, in quanto e` l'unico che oltre a CVS
ha una base di tool di terze parti tale da permetterti una integrazione
pressoche` con tutto
Enrico

 versioning, vai di Subversion.
Dipende dagli scopi e dalle conoscenze. Usare un VCS distribuito (e.g.
mercurial) potrebbe essere piu` produttivo rispetto ad utilizzare un VCS
centralizzato. Inoltre, si potrebbe essere costretti a dover scegliere
CVS nel caso ci si trovi in situazioni pregresse o in caso si voglia una
compatibilita` assoluta con i tool a disposizione
Enrico

 non andranno a creare conflitti di namespace.
vero, ma prendiamo come esempio il kernel di linux sviluppato da
migliaia di persone nel mondo.
se un giapponese decidesse di fare alcune procedure e di chiamarle xy,
come fa a tutelarsi (o come farebbero gli altri a tutelarsi) da
eventuali conflitti?
è impossibile monitorare tutti gli sviluppatori, ci sarà un modo per
farlo a posteriori....
oppure lo sviluppatore in fase di merge se nota un conflitto sistema
il suo codice per poi effettuare nuovamente il merge?
questo però non risolve da problemi di compatibilità: se la mia
funzione per funzionare necessita di alcune cose che te durante il tuo
sviluppo hai rimosso, io come faccio a saperlo?
dovrei controllare il report di ogni mergeeffettuato? è normale fare
così o ci sono delle "agevolazioni"?

 compatibilita` assoluta con i tool a disposizione
E uno voglia martellarsi le palle... :)
-- 
Vide

 cos� o ci sono delle "agevolazioni"?
Stai sovrapponendo problemi che appartengono a rami diversi
dello sviluppo del software.
Il revision control ti serve per poter gestire versioni, o
revisioni, diverse dello stesso software.
Conseguentemente, ti server per poter avere piu` sviluppatori
che lavorano sullo stesso *progetto*.
Questo, pero`, non e` la scatola magica che risolve tutti i
problemi, non per niente esistono i "merge manager", con una
"merge policy", etc.
Il revision control e` un utensile, non una soluzione.
bye,
-- 
piergiorgio

 E uno voglia martellarsi le palle... :)
Anche quelle sono scelte :P
Enrico

 come codice, che come "compatibilita`".
Un lavoro immane........


Visto lo scenario che descrivi:
. Subversion per il versionamento
. cron + tar + samba per il backup su un NAS (penso che una unità
nastro sarebbe eccessiva per voi)
qualunque altra cosa sarebbe un'inutile complicazione IMHO.
In aggiunta:
. Apache + SSL davanti a subversion per poter versionare anche da casa
(anche se un tunnel ssh va bene uguale)
. Trac per gestire i ticket ed altre cosine che fanno comodo durante
lo sviluppo.
Marius

 Un lavoro immane........
Piu` che "immane", a mio avviso, noiso.
Ci sono diversi tool, come diff e patch che aiutano
nell'operazione, ma alla fine, almeno per me, e` una
cosa a lungo andare seccante.
Puo` anche essere, pero`, che qualcuno si diverta.
bye,
-- 
piergiorgio

 .tar.bz2. Qua puoi usare quello che vuoi.
Giusto per precisare, mica fai il tbz2 della directory che contiene il
repository? Perche` se e` cosi` tu ti vuoi mooolto male (hint: la Via e`
fare un dump del repository e backuppare quello)
Enrico

 
Siccome è quasi tutto automatizzato è molto probabile che sia il
programmatore responsabile di una certa area che oltre a programmare,
esegue anche quelle incombenze divertentissime come controllare e applicare
le modifiche esterne, creare i manuali utente, la documentazione del
progetto ... andare a fare la spesa all'ipermercato all'ora di punta ....

Peregrino "Pipino" Tuc wrote:

Al 99% è tutto automatico, di manuale c'è solo la risoluzione degli
eventuali conflitti.

 eventuali conflitti.
Che sono il 99% dei casi.
Non e` solo quello, il merge, anche se automatico,
deve essere controllato.
Infatti, a volte, sbaglia clamorosamente.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

No per niente, a meno che non ci sia una gestione pesantemente scorretta
delle procedure di sviluppo (per esempio accettare patch per la versione
0.0.0 mentre l'attuale e la 9999999999.9999999.999999, non obbligare ad
usare il sistema di versioning, riscrittura trasversale di mezzo progetto,
ecc.), i conflitti sono rarissimi, specialmente usando un sistema di
versioning/patch, e non c'è bisogno di controllare tutto, i sistemi di
patch e versioning avvisano quali sono i file da controllare e consentono
di portarsi direttamente sulla zona in conflitto, eseguire la modificare,
riprocessare il file sistemato.
La parte più pesante è il controllo e test del codice, la parte meccanica di
aggiunta del codice ad un progetto è quasi trascurabile nell'intero
processo.

 riprocessare il file sistemato.
Un momento, stiamo discutendo di un progetto generico o
del kernel di Linux.
Nel primo caso, ovviamente, c'e` una pianificazione dello
sviluppo e, quindi, viene data una baseline, etc.
Nel caso di Linux, pero`, non e` cosi`.
Sia per l'uso di git, che consente di avere, in pratica
per ogni persona coinvolta, l'intero tree, sia per
politica di sviluppo.
Diversi patch provengono da versioni diversi, tocca poi
al maintainer aggiustarsi le cose.
bye,
-- 
piergiorgio

 Sia per l'uso di git, che consente di avere, in pratica
]zac[
Un minimo di pianificazione è necessario in ogni caso, per esempio se la
versione attuale è la 10 non si accettano patch provenienti dalle versione
1, infatti praticamente tutti i gestori di progetti obbligano a usare
l'ultima versione o una versione recente del codice.
Poi l'applicazione delle patch funziona in questo modo:
- Versione attuale 10.5, la versione per cui arriva la patch è 10.0.
- Lo sviluppatore fa il checkout della versione 10.0, applica in automatico
la patch ed esegue tutti test necessari.
- Lo sviluppatore esegue il comando che applica alla 10.5 le differenze tra
la versione 10.0 con le varie patch e la 10.0 senza (è un comando che
consente di applicare le modifiche tra due versioni ad un'altra
versione/tag/branch, una specie di diff/patch a tre).
In questo modo le patch vengono applicate in maniera quasi completamente
automatica e con pochi conflitti.
In questo modo nello sviluppo del kernel spesso riducono sensibilmente il
peso del porting di alcune modifiche dal kernel 2.6 al kernel 2.4, o
l'applicazione di modifiche da un fork di un kernel sperimentale.
P.S. il versioning se ben progettato facilita molte cose, come applicare in
automatico delle modifiche applicate ad un fork del progetto al progetto
principale, e con interventi manuali ridotti.
Naturalmente ci sono dei limiti, il fork non deve essere uno scaravoltamento 
totale del codice principale, un minimo di gestione del progetto è
obbligatoria.

On 14 Mag, 23:01, Enrico 'Henryx' Bianchi

Perchè? Mi è capitato spesso di dover spostare un repo di subversion
da un server ad un altro e l'ho sempre fatto con un tar del repo
stesso. Una volta fatto ripartire il server di subversion sulla nuova
macchina non ho mai avuto problemi, perciò perchè non dovrebbe
funzionare anche come metodo di backup? (senza polemica, mi
incuriosisce sapere se ci sono trappole che non ho considerato)
Marius

 sono trappole che non ho considerato)
Se sei sicuro di non avere accessi mentre fai il backup si` (in pratica 
tiri giu` il daemon che lo gestisce prima di fare il backup e lo ritiri su 
dopo).
Se invece hai anche il minimo rischio che il repository sia acceduto 
(anche solo per dei buffer in RAM non ancora scaricati), meglio fare il 
dump.
Nella stragrande maggioranza dei casi, meglio il dump.
Bye.

 incuriosisce sapere se ci sono trappole che non ho considerato)
Perche` ti porti appresso i metadati, che potrebbero
essere specifici di quel setup.
Le operazioni di dump/restore, invece, sono messe
apposta per fare quell'operazione in modo sicuro.
bye,
-- 
piergiorgio

 schedulerò un dump e backupperò quello, giusto per stare tranquillo.
L'operazione e` semplice, basta un "svnadmin dump /repository > file"
per effettuare il dump e "svnadmin load /repository < file" per
ripristinarlo (se no ricordo male, a spanne era cosi` ma ovviamente e`
sempre meglio un RTFM)
Enrico