Newsgroup: it.comp.lang.c++
Titolo: gestione documentazione di un progetto

Salve a tutti !
Io ed un mio amico ( siamo programmatori
principianti ) abbiamo cominciato a lavorare
su un progetto comune; ci teniamo in contatto
soprattutto via telefono e internet.
Abbiamo bisogno di gestire congiuntamente la
documentazione del progetto ma la faccenda non
e' affatto semplice perche'
(1)
la copia sulla mia macchina e sulla sua devono
essere mantenute sincronizzate
(2)
il materiale che ci spediamo deve essere
crittografato
Ho provato a cercare su Google, per vedere se esiste
un software freeware che risolva la nostra esigenza,
con parole del tipo
  programmazione gestione documentazione
ma vengono fuori riferimenti a programmi amministrativi
e gestionali.
Mi potreste dare qualche dritta su come procedere
in questa ricerca ?
Grazie mille e buon lavoro.
Keplero

 crittografato
Subversion attraverso ssh direi che va bene per la crittografia, per la
documentazione del codice usate Doxygen.
In pratica scrivete la documentazione direttamente nel codice, tipo:
/**
 * Questa funzione fa tante belle cose.
 */
void pinco_pallino()
{
        ...
}
Quindi, quando avete bisogno della documentazione, lanciate doxygen che
estrae tutte le stringhe e fa un manualone in diversi formati (HTML, TeX, e
quant'altro).
Ciao,
-Federico

essere mantenute sincronizzate
CVS o SVN.



CVS non lo nominerei nemmeno per sbaglio.
Infine non consiglierei SVN, se devi cominciare è probabilmente meglio un 
sistema distribuito come git, mercurial o bazaar (anche se versioni 
recenti di SVN stanno cominciando a supportare feature dei sistemi 
distribuiti).
Saluti  Manlio Perillo

 
Per prima cosa, vi ringrazio delle risposte.
Come dicevo nel mio precedente messaggio
siano novellini quindi ... ebbene si, ci
scambiamo il codice via email e "versionizzazione"
non so cosa significhi. Google restituisce
solo tre link a questa parola ...
Aiuto !!



Per Mercurial:
http://hgbook.red-bean.com/hgbook.html
(qualcuno forse lo sta anche traducendo in italiano)
Per Subversion:
http://hgbook.red-bean.com/hgbook.html
Manlio Perillo

 CVS o SVN.
Ti confesso che allungherei un bel po' la lista. Dopo avere lavorato per
un po' con git e mercurial, posso dirti che per progetti piccoli e con
pochi partecipanti IMHO avere un server centralizzato non è sempre
ideale.
Oltretutto con mercurial o git puoi *comunque* nominare un server come
repository centrale.
Io personalmente mi trovo meglio con mercurial. Preferisco git a svn,
svn a cvs (per quanto sia maledettamente e imbarazzantemente lento).
Tuttavia preferisco mercurial a git, principalmente per l'usabilità di
git. 
Oltretutto mercurial ha pure una bellissima GUI per windows della
"serie" Tortoise. Insomma, io mi ci butterei sopra al volo.
Con tutto questo meglio SVN che niente, eh. Ma chissà perchè li vedo in
procinto di essere in difficoltà a buttare su un repository SVN da 0. 
-- 
-riko

 
http://hgbook.red-bean.com/hgbook.html
Te lo appoggio! :P
-- 
-riko

 solo tre link a questa parola ...
Se vi scambiate il codice via mail allora la sicurezza non è poi così
importante (o usate GPG?).
Comunque, per «versionizzazione» intendevo il «versioning» o «controllo di
versione», vale a dire un sistema che tiene traccia delle modifiche che
vengono fatte al codice e da chi. È un'ottima cosa, è molto più utile che
tenere dei semplici backup.
Se avete un server centralizzato a disposizione, Subversion è una buona
scelta. Non sono esperto di sistemi come git e altri decentralizzati,
quindi su questi non mi esprimo, ma potrebbero essere una soluzione
migliore per voi.

Ti ringrazio per la risposta e
attraverso te tutti gli amici del
gruppo. Ci avete dato ottime indicazioni.
Buon lavoro !

 Per Subversion:
http://hgbook.red-bean.com/hgbook.html
E' intenzionale? ;-)
Ciao,
Nicola

Infine non consiglierei SVN,
Vedi sopra: lo uso quotidianamente, nessun problema.

ideale.
Io lavoro in piccoli team da secoli e non ci vedo nulla di male in
quest'approccio. Oltretutto i due tool da me citati funzionano
benissimo, mai avuto particolari problemi. Sinceramente non ho mai
notato la lentezza di cui parli...

 Vedi sopra: lo uso quotidianamente, nessun problema.
Subversion è di certo un buon prodotto, ma rispetto ai sistemi 
distribuiti citati ha il problema di:
1) La copia di lavoro prende un *sacco* di spazio per conservare 
   lo stato del repository.
   Questo stato è presente in ogni directory.
   Con Mercurial, ad esempio, non solo hai l'intera storia del repository
   in una sola directory, ma occupa anche meno spazio
2) Subversion ha problemi con il merging
3) Se non hai la connessione con il server centrale, non puoi committare
   nessuna modifica
Le ultime versioni di Subversion, comunque, stanno cercando di sistemare 
diversi problemi noti.
In definitiva, se uno deve cominciare ad usare da adesso un sistema di 
controllo versioni, credo gli convenga un sistema distribuito, che sono 
diventati abbastanza maturi.
Manlio Perillo

 notato la lentezza di cui parli...
Di SVN? Non č una cosa "di cui parlo". Č una delle lamentele piů spesso
rivolte a SVN. 
Io me ne sono accorto di primissima mano quando abbiamo fatto una
transizione da CVS a SVN (per poi tornare indietro su ordine di
$BigBoss). Effettivamente la differenza in termini di prestazioni fra i
due si vedeva.
E *non* sto dicendo che funzionano male, per inciso. Uso entrambi (in
situazioni e con progetti diversi). *E* uso Mercurial (ho usato git
pure, ma fra i due preferisco Mercurial). IMHO per la situazione
descritta Mercurial ha parecchi vantaggi.
-- 
-riko

 notato la lentezza di cui parli...
Di SVN? Non č una cosa "di cui parlo". Č una delle lamentele piů spesso


 Vedi sopra: lo uso quotidianamente, nessun problema.
Veramente anch'io li uso entrambi (progetti opensource appoggiati sui server 
di SourceForge) e funzionano benone. Certo, non conosco gli altri strumenti 
citati e quindi potrebbero essere molto migliori.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 due si vedeva.
Stai dicendo che SVN è più lento di CVS? A me risulta esattamente il 
contrario. E di molto.


 contrario. E di molto.
Uhm. Strano. Ma mica sono l'unico eh.
-- 
-riko

 Uhm. Strano. Ma mica sono l'unico eh.
Magari è il server CVS di SourceForge che è lento, non lo so, però in un 
progetto siamo passati da CVS a SVN proprio per la velocità di quest'ultimo 
e la differenza è notevole.


 diventati abbastanza maturi.
Partendo da zero probabilmente si, pero' dipende anche molto da cosa
usano i progetti che ti servono.
Ciao,
Nicola

 Vedi sopra: lo uso quotidianamente, nessun problema.
L'ho usato a lungo, ma non poter riorganizzare le proprie directory a
piacimento la trovo una limitazione inaccettabile. Purtroppo
Subversion e' migliore per certi aspetti e decisamente peggiore per
altri, in primis la gestione di branch e merge.
Ciao,
Nicola

 Uhm. Strano. Ma mica sono l'unico eh.
Il problema alla radice e' che chi ha disegnato SVN si e' concentrato
troppo sull'eliminare specifici problemi di CVS e non ha fatto
sufficiente attenzione a non perdersi aspetti positivi. Cosi' SVN e'
ben lungi dall'essere l'ideale sostituto di CVS; e' solo un altro
strumento, con altri pregi ed altri difetti.
Anche rispetto alle prestazioni hanno migliorato alcuni casi d'uso,
senza fare attenzione a non peggiorarne, e di molto, altri.
Ciao,
Nicola

 Uhm. Strano. Ma mica sono l'unico eh.
Dipende da cosa intendente per piu` lento.
- Mettere un tag su SVN e` istantaneo, su CVS ci mette un sacco di tempo 
(mette il tag su ogni directory).
- Il checkout di un progetto con SVN e` nettamente piu` veloce di CVS, 
anche usando -z3.
- L'operazione di commit e` APPARENTEMENTE piu` lenta su SVN, perche` 
prima di mandare i files viene preparato il changeset per realizzare il 
commit in modo atomico, in verita` se i files sono tanti poi il commit 
di svn risulta + veloce perche` lo e` il trasferimento.
- Sul confronto tra "cvs diff" e "svn diff", "cvs -nq update" e "svn 
status -u" e "cvs update"/"svn update" anch'io ho notato che cvs e` piu` 
veloce, ma probabilmente perche` il protocollo col server sul file 
singolo e` piu` snello, svn si porta dietro l'HTTPS, se passi CVS 
tramite ssh pero` anche CVS rallenta.
La critica piu` sensata a SVN IMHO e` lo spazio occupato da una 
repository, mostruoso rispetto a CVS che di fatto nella sua directory 
mette solo qualche filettino con le entry e i tags...
PS: Per la documentazione di un progetto C++ mi sono trovato molto bene 
con doxys (
http://www.doxys.dk
), la sintassi e` la stessa di doxygen, ma 
i manuali online generati sono molto + leggibili e comodi (in 
particolare per un uso intelligente del javascript per gestire 
l'ereditarieta' dei metodi).
Bye,
  Gabry

 Dipende da cosa intendente per piu` lento.
Be', io mi riferisco più che altro all'update che è l'operazione che viene 
fatta più frequentemente.


 Nicola
Ciao   Manlio

 Magari è il server CVS di SourceForge che è lento
No, non parlo di CVS di SoueceForge.
-- 
-riko

 senza fare attenzione a non peggiorarne, e di molto, altri.
Mi sa allora di essere finito negli "altri".
-- 
-riko

 No, non parlo di CVS di SoueceForge.
Intendevo dire: siccome io uso il CVS di SourceForge, magari ho riscontrato 
un (notevole) miglioramento passando all'SVN (sempre di SourceForge) perché 
il server CVS era lento.


   nessuna modifica
Non credo questo sia un grosso problema. Almeno, per chi sviluppa in
team, la condivisione č fondamentale.

rivolte a SVN. 
Mah... io sinceramente non noto tutta questa lentezza. 

 il server CVS era lento.
Ma hanno di recente cambiato qualcosa in SVN? Io me lo ricordo
*veramente* lancinantemente lento.
Beh, pensandoci bene lo uso con google.code... e continuo a trovarlo
lento. Boh. Sarà percezione mia. 
-- 
-riko

 lento. Boh. Sarà percezione mia.
Forse dovresti confrontarlo con il CVS.


 altri, in primis la gestione di branch e merge.
Boh, la gestione dei rami di SVN mi sembra molto più chiara che in CVS. Nel
gruppo di traduzione di KDE in italiano (dove abbiamo usato prima CVS e
adesso siamo su SVN) abbiamo avuto casini immani con la gestione dei rami
di CVS, legati essenzialmente al fatto che a volte qualcuno si dimenticava
di aggiornare qualche file della copia locale e finiva per lavorare sul
file sbagliato. Invece in SVN basta stare nella cartella giusta, e fine
della storia.
Per quanto riguarda la fusione, non l'ho usata molto su CVS, ma in SVN mi
sembra abbastanza chiara (posto che non ho molta esperienza comparata con
altri sistemi, eh), sempre che qualcuno si ricordi di scrivere sempre una
voce di registro descrittiva quando si deposita una modifica.
Ciao,
-Federico

 Forse dovresti confrontarlo con il CVS.
Quello lo uso. Il nostro. Che poi dovrebbe essere quello standard che
sta su Fedora X, dove X è probabilmente Core 9 ma dovrei controllare.
-- 
-riko

 ha scritto nel messaggio 
news:1iohgcs.1ftz0cz12ic4w0N%ri...@despammed.com...
In ogni caso, SourceForge ha recentemente riorganizzato i suoi server e devo 
dire che, almeno al momento, la differenza rispetto a prima č abissale e il 
CVS ora sembra veloce quanto l'SVN.


Io uso mercurial con Sourceforge, e da quello che mi pare di capire e'
il server di sourceforge che e' lento.
Uso mercurial con Sharesource ed e' decisamente piu' veloce di
sourceforge.
Per un novello di sistemi di source code management, direi che e'
meglio partire con Mercurial.
Se si impara CVS o SVN o Perforce, finisce male. E lo dico con il
senno di uno che fa da amministratore a vari sistemi e ha introdotto
mercurial in azienda.
Se non sai cosa e' un SCM, Mercurial e' la scelta giusta.
Tra l'altro, usando Mercurial (o git) scambiarsi il codice via email
e' comodissimo, e puoi criptare i messaggi con GPG in automatico.
Il passo successive e' imparare a usare le Mercurial Queues che sono
il pane quotidiano di sviluppatori open source.

 team, la condivisione è fondamentale.
Ci sono altri metodi di condivisione.
Per me è un grosso problema.
Supponi di aver creato un tuo branch per aggiungere una feature.
Con un repository centrale devi connetterti ogni volta al server; con un 
sistema distribuito no.
Ciao  Manlio