Il giorno 25/ott/07, alle ore 18:15, 0bscure ha scritto: Questo è irrilevante. Magari un prodotto pensato principalmente per la gestione di codice sorgente può non adattarsi alle tue necessità per la documentazione, che sinceramente non ho ben compreso, ma la questione di "dove metterlo" non è certo un problema. Puoi usare ad esempio Git (git.or.cz) che è distribuito, non richiede un server centrale né demoni in esecuzione o altro. Lavora solo quando lo lanci per fare qualche operazione e il repository è interamente basato su filesystem, in una directory .git all'interno del progetto gestito dal repository. E' lo stesso software usato per gestire i sorgenti di Linux (il kernel, intendo). Per un uso all'interno di un team di sviluppo (anche se si sviluppa documentazione e non codice) di solito va molto bene, anche perché è distribuito. I push/pull tra gli sviluppatori sono possibili tramite ssh o rsync, e se vuoi un repository "centralizzato" basta mettere git su qualche macchina e tutti fanno push/pull da quella. Un grande pregio è la semplicità di gestire svariati branch, e questo spesso semplifica la vita agli sviluppatori. Se vuoi sentire qualcosa di più in merito, io ho trovato molto interessanti l'intervista a Junio Hamano (maintainer di Git) su FLOSS Weekly[1] e il talk di Torvalds in Google[2]. Quest'ultimo in realtà spiega di più come è fatto e perché è fatto così Git, in particolar modo sull'aspetto distribuito e non centralizzato, oltre ad essere divertente per il modo in cui Torvalds insulta a più riprese CVS ed SVN :) La puntata di FLOSS è più, se vogliamo, orientata ai vantaggi di Git nell'uso quotidiano. Ovviamente c'è anche l'immancabile articolo su wikipedia[3]. Poi ripeto, facile che tu abbia altre necessità che un revision control non soddisfa, però non porti il problema del "server". -- Luca Lesinigo |