1846 lines
75 KiB
XML
1846 lines
75 KiB
XML
<?xml version="1.0" encoding="iso-8859-15"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
|
|
"../../../share/xml/freebsd45.dtd">
|
|
|
|
<!--
|
|
The FreeBSD Italian Documentation Project
|
|
|
|
$FreeBSD$
|
|
Original revision: 1.219
|
|
-->
|
|
|
|
<article lang="it">
|
|
<articleinfo>
|
|
<title>Guida del Committer</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<surname>The FreeBSD Italian Documentation Project</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<copyright>
|
|
<year>1999</year>
|
|
|
|
<year>2000</year>
|
|
|
|
<year>2001</year>
|
|
|
|
<year>2002</year>
|
|
|
|
<year>2003</year>
|
|
|
|
<year>2004</year>
|
|
|
|
<holder>The FreeBSD Italian Documentation Project</holder>
|
|
</copyright>
|
|
|
|
<legalnotice id="trademarks" role="trademarks">
|
|
&tm-attrib.freebsd;
|
|
&tm-attrib.cvsup;
|
|
&tm-attrib.ibm;
|
|
&tm-attrib.intel;
|
|
&tm-attrib.sparc;
|
|
&tm-attrib.general;
|
|
</legalnotice>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
|
|
<abstract>
|
|
<para>Questo documento fornisce informazioni per la comunità dei
|
|
committer di FreeBSD. Tutti i nuovi committer dovrebbero leggere
|
|
questo documento prima di iniziare, e i committer già esistenti
|
|
sono fortemente incoraggiati a riguardarselo di tanto in tanto.</para>
|
|
|
|
&trans.it.alex;
|
|
</abstract>
|
|
</articleinfo>
|
|
|
|
<sect1 id="admin">
|
|
<title>Dettagli Amministrativi</title>
|
|
|
|
<informaltable frame="none" orient="port" pgwide="1">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><emphasis>Host con il Repository
|
|
Principale</emphasis></entry>
|
|
|
|
<entry><hostid role="fqdn">ncvs.FreeBSD.org</hostid></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>Metodi di Accesso</emphasis></entry>
|
|
|
|
<entry>&man.ssh.1;, solo protocollo 2</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>CVSROOT Principale</emphasis></entry>
|
|
|
|
<entry><hostid
|
|
role="fqdn">ncvs.FreeBSD.org</hostid><literal>:</literal><filename>/home/ncvs</filename>
|
|
(guarda anche la <xref linkend="cvs.operations"/>).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>&a.cvsadm; Principali</emphasis></entry>
|
|
|
|
<entry>&a.peter; e &a.markm;, così come &a.joe; e &a.marcus;
|
|
per i <filename>ports/</filename></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>Mailing List</emphasis></entry>
|
|
|
|
<entry>&a.doc-developers;, &a.doc-committers;;
|
|
&a.ports-developers;, &a.ports-committers;;
|
|
&a.src-developers;, &a.src-committers;. (Ogni repository di
|
|
progetto ha le sue mailing list -developers e -committers. Gli
|
|
archivi per queste liste possono essere trovati nei file
|
|
<filename>/home/mail/<replaceable>repository-name</replaceable>-developers-archive</filename>
|
|
e
|
|
<filename>/home/mail/<replaceable>repository-name</replaceable>-committers-archive</filename>
|
|
sul cluster di <hostid
|
|
role="domainname">FreeBSD.org</hostid>.)</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>Report mensili del Core Team</emphasis></entry>
|
|
<entry><filename>/home/core/public/monthly-report</filename>
|
|
sul cluster di <hostid
|
|
role="domainname">FreeBSD.org</hostid>.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><emphasis>Tag CVS Degni di Nota</emphasis></entry>
|
|
|
|
<entry><literal>RELENG_4</literal> (4.X-STABLE),
|
|
<literal>RELENG_5</literal> (5.X-STABLE),
|
|
<literal>HEAD</literal> (-CURRENT)</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>È richiesto l'uso di &man.ssh.1; o &man.telnet.1; con
|
|
Kerberos 5 per connettersi agli host del progetto. Per &man.ssh.1;
|
|
è permesso solo il protocollo 2.
|
|
Questi sono generalmente più sicuri che un semplice &man.telnet.1;
|
|
o &man.rlogin.1; visto che la negoziazione delle credenziali
|
|
avverrà sempre in modo cifrato.
|
|
Tutto il traffico è cifrato di default
|
|
con &man.ssh.1;. Insieme a programmi di utilità come
|
|
&man.ssh-agent.1; e &man.scp.1;, anch'essi disponibili, &man.ssh.1;
|
|
è di gran lunga più conveniente. Se non sai nulla di
|
|
&man.ssh.1;, guarda la <xref linkend="ssh.guide"/>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="committer.types">
|
|
<title>Tipi di Bit di Commit</title>
|
|
|
|
<para>Il repository CVS di FreeBSD ha un numero di componenti che, se
|
|
combinati, supportano i sorgenti di base del sistema operativo, la
|
|
documentazione, l'infrastruttura dei port delle applicazioni di terze
|
|
parti, e vari programmi di utilità. Quando vengono assegnati i bit
|
|
di commit di FreeBSD, vengono specificate le aree dell'albero dove il bit
|
|
può essere usato. Solitamente, le aree associate a un bit
|
|
corrispondono a quelle di chi ha autorizzato l'assegnamento del bit di
|
|
commit. Ulteriori aree di autorità possono essere aggiunte in
|
|
seguito: se occorrerà, il committer dovrà seguire le
|
|
normali procedure di allocazione del bit di commit per quell'area
|
|
dell'albero, chiedendo l'approvazione all'entità appropriata e
|
|
possibilmente prendendo un mentore per quell'area per un po' di
|
|
tempo.</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="3">
|
|
<tbody>
|
|
<row>
|
|
<entry><emphasis>Tipo di Committer</emphasis></entry>
|
|
|
|
<entry><emphasis>Responsabile</emphasis></entry>
|
|
|
|
<entry><emphasis>Componenti dell'Albero</emphasis></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>src</entry>
|
|
|
|
<entry>core@</entry>
|
|
|
|
<entry>src/, doc/ soggetta ad appropriata revisione</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>doc</entry>
|
|
|
|
<entry>doceng@</entry>
|
|
|
|
<entry>doc/, www/, documentazione src/</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ports</entry>
|
|
|
|
<entry>portmgr@</entry>
|
|
|
|
<entry>ports/</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>I bit di commit assegnati prima dello sviluppo della nozione di aree
|
|
di autorità possono essere usati in molte parti dell'albero.
|
|
Tuttavia, il buon senso dice che un committer che non ha mai lavorato
|
|
precedentemente in un'area dell'albero chieda una revisione del proprio
|
|
lavoro prima di effettuare il commit, chieda l'approvazione del
|
|
responsabile appropriato, e/o lavori d'accordo con un mentore. Dato che
|
|
le regole sulla manutenzione del codice differiscono a seconda dell'area
|
|
dell'albero, questo è per il bene del committer che lavora in
|
|
un'area poco familiare tanto quanto per gli altri che lavorano
|
|
sull'albero.</para>
|
|
|
|
<para>I committer sono incoraggiati a chiedere la revisione del proprio
|
|
lavoro come parte del normale processo di sviluppo, indifferentemente
|
|
dall'area dell'albero in cui stanno lavorando.</para>
|
|
|
|
<sect2>
|
|
<title>Regolamento dell'attività del <filename>doc/</filename>
|
|
committer in <filename>src/</filename></title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>I doc committer possono effettuare commit riguardanti modifiche
|
|
alla documentazione sui file src, come pagine man, README,
|
|
database dei fortune, file dei calendari, e correzioni sui commenti
|
|
senza l'approvazione di un src committer, prestando la solita
|
|
attenzione e cura ai commit.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>I doc committer possono effettuare commit riguardanti piccole
|
|
modifiche e correzioni ai sorgenti, come correzioni per la
|
|
compilazione, piccole funzionalità, ecc., con un
|
|
<quote>Approved by</quote> di un src committer.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>I doc committer possono cercare di ottenere il commit bit sui
|
|
src acquisendo un mentore, che proporrà il doc committer al
|
|
core. Una volta approvato, verrà aggiunto al file
|
|
<filename>access</filename> ed inizierà il normale periodo
|
|
sotto la guida del mentore, che implica l'aggiunta di
|
|
<quote>Approved by</quote> per un certo periodo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><quote>Approved by</quote> può essere usato solamente
|
|
se l'approvazione è di un src committer senza mentore —
|
|
i committer ancora sotto la guida di un mentore possono fornire al
|
|
più un <quote>Reviewed by</quote> ma non un
|
|
<quote>Approved by</quote>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="cvs.operations">
|
|
<title>Operazioni sul CVS</title>
|
|
|
|
<para>Si assume che tu abbia già familiarità con le operazioni
|
|
di base di CVS.</para>
|
|
|
|
<para>I &a.cvsadm; sono i <quote>proprietari</quote> del repository CVS e
|
|
sono responsabili delle sue modifiche dirette allo scopo di ripulire o
|
|
sistemare dei gravi abusi di CVS da parte di un committer.
|
|
Nel caso dovessi causare qualche problema al repository,
|
|
diciamo una errata operazione di <command>cvs import</command> o
|
|
<command>cvs tag</command>, invia un messaggio al membro responsabile
|
|
fra i &a.cvsadm;, come stabilito nella tabella qui sotto, (o chiama uno
|
|
di loro) ed esponi il problema. Per questioni molto importanti che
|
|
interessano l'intero albero CVS—non solo un'area
|
|
specifica—puoi contattare i &a.cvsadm;. <emphasis>Non</emphasis>
|
|
contattare i &a.cvsadm; per copie di repository o altre cose che possono
|
|
gestire i team più specifici.</para>
|
|
|
|
<para>Gli unici che hanno il
|
|
permesso di manipolare direttamente i bit del repository sono i
|
|
<quote>repomeister</quote>. Per questo non ci sono shell di login
|
|
disponibili sulle macchine del repository, tranne che per i
|
|
repomeister.</para>
|
|
|
|
<note>
|
|
<para>A seconda dell'area interessata del repository CVS, dovresti
|
|
mandare la tua richiesta a uno dei seguenti indirizzi email:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>ncvs@ - a proposito di <filename
|
|
role="directory">/home/ncvs</filename>, il repository dei
|
|
src</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>pcvs@ - a proposito di <filename
|
|
role="directory">/home/pcvs</filename>, il repository dei
|
|
port</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>dcvs@ - a proposito di <filename
|
|
role="directory">/home/dcvs</filename>, il repository dei
|
|
doc</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>projcvs@ - a proposito di <filename
|
|
role="directory">/home/projcvs</filename>, il repository dei
|
|
progetti di terze parti</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</note>
|
|
|
|
<para>L'albero CVS è attualmente diviso in quattro repository
|
|
differenti, ovvero <literal>doc</literal>, <literal>ports</literal>,
|
|
<literal>projects</literal> e <literal>src</literal>. Questi vengono
|
|
ricomposti sotto un unico <literal>CVSROOT</literal> quando vengono
|
|
distribuiti tramite <application>CVSup</application> per la convenienza
|
|
dei nostri utenti.</para>
|
|
|
|
<note>
|
|
<para>Nota che il modulo <literal>www</literal> che contiene i sorgenti
|
|
del <ulink url="http://www.FreeBSD.org">sito web di FreeBSD</ulink>
|
|
è contenuto all'interno del repository
|
|
<literal>doc</literal>.</para>
|
|
</note>
|
|
|
|
<para>I repository CVS sono ospitati sulle macchine repository.
|
|
Attualmente, ognuno dei repository elencati qui sopra risiede sulla stessa
|
|
macchina fisica, <hostid role="hostname">ncvs.FreeBSD.org</hostid>, ma
|
|
per permettere la possibilità di averne ognuno su una macchina
|
|
diversa in futuro, ci sono diversi nomi di host che i committer
|
|
dovrebbero utilizzare. Inoltre, ogni repository risiede in una
|
|
directory differente. La seguente tabella racchiude la situazione.</para>
|
|
|
|
<table frame="none" id="cvs-repositories-and-hosts">
|
|
<title>Repository CVS, Host e Directory di &os;</title>
|
|
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Repository</entry>
|
|
|
|
<entry>Host</entry>
|
|
|
|
<entry>Directory</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>doc</entry>
|
|
|
|
<entry>dcvs.FreeBSD.org</entry>
|
|
|
|
<entry>/home/dcvs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ports</entry>
|
|
|
|
<entry>pcvs.FreeBSD.org</entry>
|
|
|
|
<entry>/home/pcvs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>projects</entry>
|
|
|
|
<entry>projcvs.FreeBSD.org</entry>
|
|
|
|
<entry>/home/projcvs</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>src</entry>
|
|
|
|
<entry>ncvs.FreeBSD.org</entry>
|
|
|
|
<entry>/home/ncvs</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Le operazioni sul CVS sono fatte da remoto impostando la variabile di
|
|
ambiente <envar>CVSROOT</envar> a <hostid
|
|
role="fqdn">ncvs.FreeBSD.org</hostid><literal>:</literal><filename>/home/ncvs</filename>
|
|
e la variabile <envar>CVS_RSH</envar> a <command>ssh</command>, e
|
|
quindi effettuando le appropriate operazioni di check-out/check-in.
|
|
Molti committer definiscono degli alias che si espandono nella corretta
|
|
invocazione di <application>cvs</application> per il repository
|
|
appropriato. Per esempio, un utente di &man.tcsh.1; può aggiungere
|
|
le seguenti righe al suo <filename>.cshrc</filename> per questo
|
|
scopo:</para>
|
|
|
|
<programlisting>alias dcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@dcvs.FreeBSD.org:/home/dcvs
|
|
alias pcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@pcvs.FreeBSD.org:/home/pcvs
|
|
alias projcvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@projcvs.FreeBSD.org:/home/projcvs
|
|
alias scvs env CVS_RSH=ssh cvs -d <replaceable>user</replaceable>@ncvs.FreeBSD.org:/home/ncvs</programlisting>
|
|
|
|
<para>In questo modo è possibile fare tutte le operazioni di
|
|
CVS localmente ed usare <command><replaceable>X</replaceable>cvs
|
|
commit</command> per effettuare il commit sull'albero CVS ufficiale.
|
|
Se desideri aggiungere qualcosa di totalmente nuovo (ad esempio dei
|
|
sorgenti in contrib, ecc.), deve essere usato <command>cvs
|
|
import</command>. Guarda come riferimento la pagina man di &man.cvs.1;
|
|
per l'utilizzo.</para>
|
|
|
|
<note>
|
|
<para>Per favore <emphasis>non</emphasis> usare <command>cvs
|
|
checkout</command> o <command>update</command> con la macchina con il
|
|
repository ufficiale impostata come CVS Root per tenere aggiornato il
|
|
tuo albero dei sorgenti. CVS da remoto non è ottimizzato per la
|
|
distribuzione via rete e richiede un grande sovraccarico di lavoro e di
|
|
amministrazione sul lato server. Utilizza il nostro metodo di
|
|
distribuzione avanzato <command>cvsup</command> per ottenere i bit del
|
|
repository, ed esegui solamente l'operazione di
|
|
<command>commit</command> sull'host con il repository.
|
|
Forniamo un'estesa rete di mirror cvsup per questo scopo, così
|
|
come diamo accesso al <hostid>cvsup-master</hostid> se hai veramente
|
|
bisogno di essere aggiornato alle ultime modifiche.
|
|
Il <hostid>cvsup-master</hostid> ha la potenza necessaria a gestire
|
|
questa cosa, il repository principale no. &a.kuriyama; è a capo
|
|
del <hostid>cvsup-master</hostid>.</para>
|
|
</note>
|
|
|
|
<para>Se devi usare le operazioni <command>add</command> e
|
|
<command>delete</command> di CVS come se fosse un'operazione &man.mv.1;,
|
|
allora va effettuata una copia nel repository piuttosto che usare
|
|
<command>add</command> e <command>delete</command> di CVS. In una
|
|
copia nel repository, un <link linkend="conventions">CVS Meister</link>
|
|
copierà il/i file nei loro nuovi nomi e/o locazioni e ti
|
|
avviserà ad operazione avvenuta. Lo scopo di una copia del
|
|
repository è di preservare la cronologia dei cambiamenti del file,
|
|
o i log. Noi del FreeBSD Project diamo molta importanza alla cronologia
|
|
dei cambiamenti che CVS fornisce al progetto.</para>
|
|
|
|
<para>Informazioni di riferimento, tutorial, e FAQ su CVS possono
|
|
essere trovate su: <ulink url="http://www.cvshome.org/docs/"></ulink>.
|
|
Anche le informazioni contenute nei <ulink
|
|
url="http://cvsbook.red-bean.com/cvsbook.html">capitoli di Karl Fogel
|
|
da <quote>Open Source Development with CVS</quote></ulink> sono molto
|
|
utili.</para>
|
|
|
|
<para>&a.des; ha fornito inoltre il seguente <quote>mini manuale</quote> su
|
|
CVS.</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Effettua il check out di un modulo con il comando
|
|
<command>co</command> o <command>checkout</command>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs checkout shazam</userinput></screen>
|
|
|
|
<para>Questo estrae una copia del modulo <filename>shazam</filename>. Se
|
|
non c'è alcun modulo <filename>shazam</filename> nel file dei
|
|
moduli, cercherà allora una directory di primo livello chiamata
|
|
<filename>shazam</filename>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Opzioni utili con <command>cvs checkout</command></title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><option>-P</option></entry>
|
|
|
|
<entry>Non crea le directory vuote</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-l</option></entry>
|
|
|
|
<entry>Estrae solo un livello, non le sottodirectory</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-r<replaceable>ver</replaceable></option></entry>
|
|
|
|
<entry>Estrai la versione, il ramo, o il tag
|
|
<replaceable>ver</replaceable></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-D<replaceable>data</replaceable></option></entry>
|
|
|
|
<entry>Estrai i sorgenti com'erano in data
|
|
<replaceable>data</replaceable></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Esempi pratici su FreeBSD:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Estrai il modulo <filename>miscfs</filename>, che
|
|
corrisponde a <filename>src/sys/miscfs</filename>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co miscfs</userinput></screen>
|
|
|
|
<para>Ora hai una directory chiamata <filename>miscfs</filename>
|
|
con le sottodirectory <filename>CVS</filename>,
|
|
<filename>deadfs</filename>, <filename>devfs</filename>, e
|
|
così via. Una di queste (<filename>linprocfs</filename>)
|
|
è vuota.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai gli stessi file, ma con il percorso completo:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co src/sys/miscfs</userinput></screen>
|
|
|
|
<para>Ora hai una directory chiamata <filename>src</filename>,
|
|
con le sottodirectory <filename>CVS</filename> e
|
|
<filename>sys</filename>. La directory
|
|
<filename>src/sys</filename> ha le
|
|
sottodirectory <filename>CVS</filename> e
|
|
<filename>miscfs</filename>, ecc.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai gli stessi file, ma elimina le directory vuote:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -P miscfs</userinput></screen>
|
|
|
|
<para>Ora hai una directory chiamata <filename>miscfs</filename>
|
|
con le sottodirectory <filename>CVS</filename>,
|
|
<filename>deadfs</filename>, <filename>devfs</filename>... ma nota
|
|
che non c'è nessuna sottodirectory
|
|
<filename>linprocfs</filename>, perché non contiene alcun
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai la directory <filename>miscfs</filename>, ma nessuna
|
|
delle sue sottodirectory:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -l miscfs</userinput></screen>
|
|
|
|
<para>Ora hai una a directory chiamata <filename>miscfs</filename>
|
|
con solo una sottodirectory chiamata
|
|
<filename>CVS</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai il modulo <filename>miscfs</filename> com'è nel
|
|
ramo 4.X:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -rRELENG_4 miscfs</userinput></screen>
|
|
|
|
<para>Puoi modificare i sorgenti ed effettuare il commit su questo
|
|
ramo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai il modulo <filename>miscfs</filename> com'era nella
|
|
3.4-RELEASE.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -rRELENG_3_4_0_RELEASE miscfs</userinput></screen>
|
|
|
|
<para>Non potrai effettuare il commit delle modifiche, visto che
|
|
<literal>RELENG_3_4_0_RELEASE</literal> corrisponde ad un
|
|
preciso istante di tempo, non a un ramo.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai il modulo <filename>miscfs</filename> com'era il 15
|
|
gennaio 2000.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -D'01/15/2000' miscfs</userinput></screen>
|
|
|
|
<para>Non potrai effettuare modifiche.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Estrai il modulo <filename>miscfs</filename> com'era una
|
|
settimana fa.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -D'last week' miscfs</userinput></screen>
|
|
|
|
<para>Non potrai effettuare modifiche.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Tieni presente che cvs salva i metadati in sottodirectory chiamate
|
|
<filename>CVS</filename>.</para>
|
|
|
|
<para>Gli argomenti di <option>-D</option> e <option>-r</option>
|
|
sono fissi, che vuol dire che cvs se li ricorderà in seguito,
|
|
ad esempio quando farai un <command>cvs update</command>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Controlla lo stato dei file estratti con il comando
|
|
<command>status</command>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs status shazam</userinput></screen>
|
|
|
|
<para>Questo visualizza lo stato del file <filename>shazam</filename> o
|
|
di ogni file nella directory <filename>shazam</filename>. Per ogni
|
|
file, lo stato è uno fra:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>Up-to-date</entry>
|
|
|
|
<entry>Il file à aggiornato e non è stato
|
|
modificato.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Needs Patch</entry>
|
|
|
|
<entry>Il file non è stato modificato, ma c'è una
|
|
nuova versione nel repository.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Locally Modified</entry>
|
|
|
|
<entry>Il file è aggiornato, ma è stato
|
|
modificato.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Needs Merge</entry>
|
|
|
|
<entry>Il file è stato modificato, e c'è una nuova
|
|
versione nel repository.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>File had conflicts on merge</entry>
|
|
|
|
<entry>Ci sono stati conflitti l'ultima volta che il file
|
|
è stato aggiornato, e non sono ancora stati
|
|
risolti.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>Vedrai anche la versione e la data locale, il numero dell'ultima
|
|
versione appropriata (<quote>ultima appropriata</quote> perché
|
|
se hai una data, un tag o un ramo fissati, può non essere
|
|
l'ultima versione), e i tag, le date o le opzioni applicate.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Dopo avere estratto qualcosa, puoi aggiornarlo con il comando
|
|
<command>update</command>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs update shazam</userinput></screen>
|
|
|
|
<para>Questo aggiorna il file <filename>shazam</filename> o il contenuto
|
|
della directory <filename>shazam</filename> all'ultima versione sul
|
|
ramo che hai estratto. Se hai estratto un <quote>preciso instante di
|
|
tempo</quote>, non fa nulla a meno che i tag non siano stati
|
|
spostati nel repository o qualche altra strana cosa sia in
|
|
corso.</para>
|
|
|
|
<para>Opzioni utili, in aggiunta a quelle elencate sopra, con
|
|
<command>checkout</command>:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><option>-d</option></entry>
|
|
|
|
<entry>Estrae ogni directory aggiuntiva mancante.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-A</option></entry>
|
|
|
|
<entry>Scarica l'ultima versione del ramo principale.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-j<replaceable>ver</replaceable></option></entry>
|
|
|
|
<entry>Altre magie (guarda sotto).</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>Se hai estratto un modulo con <option>-r</option> o
|
|
<option>-D</option>, l'esecuzione di <command>cvs update</command>
|
|
con un argomento differente di <option>-r</option> o
|
|
<option>-D</option> o con <option>-A</option> selezionerà un
|
|
nuovo ramo, una nuova versione o una nuova data.
|
|
L'opzione <option>-A</option> elimina tutti i tag, le date o le
|
|
versioni fissate mentre <option>-r</option> e <option>-D</option> ne
|
|
impostano di nuove.</para>
|
|
|
|
<para>Teoricamente, specificando <literal>HEAD</literal> come argomento
|
|
di <option>-r</option> avrai lo stesso risultato di
|
|
<option>-A</option>, ma è solo in teoria.</para>
|
|
|
|
<para>L'opzione <option>-d</option> è utile se:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>qualcuno ha aggiunto delle sottodirectory al modulo che hai
|
|
estratto dopo averlo estratto.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>hai estratto con <option>-l</option>, e dopo cambi idea e
|
|
vuoi estrarre anche le sottodirectory.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>hai cancellato delle sottodirectory e vuoi estrarle
|
|
nuovamente.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para><emphasis>Osserva l'output di <command>cvs update</command> con
|
|
cura</emphasis>. La lettera all'inizio di ogni file indica cosa
|
|
è stato fatto su di esso:</para>
|
|
|
|
<informaltable frame="none" pgwide="1">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><literal>U</literal></entry>
|
|
|
|
<entry>Il file è stato aggiornato senza problemi.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>P</literal></entry>
|
|
|
|
<entry>Il file è stato aggiornato senza problemi (vedrai
|
|
questo solo quando lavorerai su un repository remoto).</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>M</literal></entry>
|
|
|
|
<entry>Il file è stato modificato, ed è stato
|
|
fuso senza conflitti.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><literal>C</literal></entry>
|
|
|
|
<entry>Il file è stato modificato, ed è stato
|
|
fuso con dei conflitti.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>La fusione è ciò che avviene quando estrai una copia
|
|
di qualche codice sorgente, lo modifichi, quindi qualcun altro
|
|
effettua il commit di un'altra modifica, e tu esegui <command>cvs
|
|
update</command>. CVS nota che tu hai fatto dei cambiamenti locali, e
|
|
cerca di fondere le tue modifiche con quelle fatte tra la versione che
|
|
hai originariamente estratto e quella che stai aggiornando. Se i
|
|
cambiamenti sono a due parti separate del file, solitamente non ci
|
|
saranno problemi (sebbene il risultato possa non essere
|
|
sintatticamente o semanticamente corretto).</para>
|
|
|
|
<para>CVS stamperà una <literal>M</literal> davanti ad ogni file
|
|
modificato localmente anche se non c'è una nuova versione nel
|
|
repository, quindi <command>cvs update</command> è adatto
|
|
per avere un resoconto di quello che hai cambiato in locale.</para>
|
|
|
|
<para>Se appare una <literal>C</literal>, allora le tue modifiche sono
|
|
in conflitto con i cambiamenti presenti nel repository (le modifiche
|
|
sono sulle stesse righe, o righe vicine, o hai cambiato così
|
|
tanto il file locale che <command>cvs</command> non è in grado
|
|
di applicare le modifiche al repository). Dovrai allora andare a
|
|
modificare il file a mano e risolvere i conflitti; questi saranno
|
|
evidenziati da righe di simboli <literal><</literal>,
|
|
<literal>=</literal> e <literal>></literal>. Per ogni conflitto,
|
|
ci sarà una linea di demarcazione formata da sette
|
|
<literal><</literal> e il nome del file, seguita da una porzione di
|
|
quello che il tuo file locale conteneva, seguita da una riga di
|
|
separazione con sette <literal>=</literal>, seguita dalla porzione
|
|
corrispondente presente nella versione del repository, seguita da una
|
|
riga di separazione con sette <literal>></literal> e il numero di
|
|
versione che stai aggiornando.</para>
|
|
|
|
<para>L'opzione <option>-j</option> è un po' voodoo. Aggiorna
|
|
il file locale alla versione specificata come se avessi usato
|
|
<option>-r</option>, ma non cambia il numero di versione o il ramo
|
|
registrato del file locale. Non è realmente utile tranne
|
|
quando usata due volte, nel qual caso fonderà le modifiche
|
|
tra le due versioni specificate nella copia su cui stai
|
|
lavorando.</para>
|
|
|
|
<para>Per esempio, supponiamo che ti abbia effettuato il commit di una
|
|
modifica a <filename>shazam/shazam.c</filename> in &os.current; e che
|
|
più tardi tu voglia effettuare l'MFC. Le modifiche che vuoi
|
|
fondere sono nella versione 1.15:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Estrai la versione &os.stable; del modulo
|
|
<filename>shazam</filename>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs co -rRELENG_5 shazam</userinput></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Applica le modifiche tra la ver 1.14 e la 1.15:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs update -j1.14 -j1.15 shazam/shazam.c</userinput></screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Quasi certamente avrai un conflitto a causa delle righe
|
|
<literal>$<!-- blocca l'espansione -->Id<!-- blocca l'espansione
|
|
-->$</literal> (o nel caso di FreeBSD, <literal>$<!-- blocca
|
|
l'espansione -->FreeBSD<!-- blocca l'espansione -->$</literal>),
|
|
quindi dovrai modificare a mano il file per risolvere il conflitto
|
|
(rimuovi le righe di separazione e la seconda linea
|
|
<literal>$<!-- blocca l'espansione -->Id<!-- blocca l'espansione
|
|
-->$</literal>, lasciando la linea <literal>$<!-- blocca
|
|
l'espansione -->Id<!-- blocca l'espansione -->$</literal>
|
|
originale intatta).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Guarda le differenze tra la versione locale e quella sul
|
|
repository con il comando <command>diff</command>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs diff shazam</userinput></screen>
|
|
|
|
<para>mostra ogni modifica che hai fatto al file o al modulo
|
|
<filename>shazam</filename>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Opzioni utili con <command>cvs diff</command></title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><option>-u</option></entry>
|
|
|
|
<entry>Utilizza il formato diff unificato.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-c</option></entry>
|
|
|
|
<entry>Utilizza il formato diff contestuale.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-N</option></entry>
|
|
|
|
<entry>Visualizza i file mancanti o aggiunti.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Vorrai sempre utilizzare <option>-u</option>, visto che le diff
|
|
unificate sono molto più semplici da leggere rispetto a quasi
|
|
tutti gli altri formati (in alcune circostanze, le diff contestuali
|
|
generate con l'opzione <option>-c</option> possono essere meglio, ma
|
|
sono molto più voluminose). Una diff unificata consiste di una
|
|
serie di parti. Ogni parte inizia con una riga con due caratteri
|
|
<literal>@</literal> e specifica dove si trovano le differenze nel
|
|
file e su quante linee si estendono. Questa è seguita da un
|
|
certo numero di righe; alcune (precedute da uno spazio) fanno parte
|
|
del contesto; altre (precedute da un <literal>-</literal>) sono quelle
|
|
eliminate e altre ancora (precedute da un <literal>+</literal>) sono
|
|
quelle aggiunte.</para>
|
|
|
|
<para>Puoi anche effettuare una diff con una versione differente
|
|
rispetto a quella che hai estratto specificando la versione con
|
|
<option>-r</option> o <option>-D</option> come per il
|
|
<command>checkout</command> o l'<command>update</command>,
|
|
o anche visualizzare le differenze tra due versioni arbitrarie
|
|
(indipendentemente da quella che hai localmente) specificando
|
|
<emphasis>due</emphasis> versioni con <option>-r</option> o
|
|
<option>-D</option>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Guarda le righe di log con il comando
|
|
<command>log</command>.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs log shazam</userinput></screen>
|
|
|
|
<para>Se <filename>shazam</filename> è un file, questo
|
|
stamperà un'<emphasis>intestazione</emphasis> con le
|
|
informazioni sul file, come la locazione nel repository dove il file
|
|
è salvato, a quale versione è l'<literal>HEAD</literal>
|
|
per questo file, in quali rami si trova il file, e qualsiasi tag
|
|
valido per questo file. Quindi, per ogni versione del file, viene
|
|
stampato un messaggio di log. Questo include la data e l'ora del
|
|
commit, chi ha fatto il commit, quante righe sono state aggiunte e/o
|
|
tolte, e alla fine il messaggio di log che il committer ha scritto
|
|
quando ha inviato la modifica.</para>
|
|
|
|
<para>Se <filename>shazam</filename> è una directory, allora le
|
|
informazioni di log descritte sopra vengono stampate a turno per ogni
|
|
file presente nella directory. A meno che tu abbia dato l'opzione
|
|
<option>-l</option> a <command>log</command>, vengono stampati anche
|
|
i log per tutte le sottodirectory di <filename>shazam</filename>, in
|
|
maniera ricorsiva.</para>
|
|
|
|
<para>Usa il comando <command>log</command> per vedere la storia di uno
|
|
o più file, come è salvata nel repository CVS. Puoi
|
|
anche usarlo per vedere il messaggio di log di una versione specifica,
|
|
se aggiungi <option>-r<replaceable>ver</replaceable></option> al
|
|
comando <command>log</command>:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs log -r1.2 shazam</userinput></screen>
|
|
|
|
<para>Questo stamperà solamente il messaggio di log per la
|
|
versione <literal>1.2</literal> del file <filename>shazam</filename>
|
|
se è un file, oppure i messaggi di log per le versioni 1.2 di
|
|
ogni file sotto <filename>shazam</filename> se è una
|
|
directory.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Guarda chi ha fatto cosa con il comando
|
|
<command>annotate</command>. Questo comando visualizza ogni riga del
|
|
file o dei file specificati, insieme all'utente che ha modificato
|
|
più recentemente quella riga.</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs annotate shazam</userinput></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Aggiungi nuovi file con il comando <command>add</command>.</para>
|
|
|
|
<para>Crea il file, usa <command>cvs add</command> su di esso, quindi
|
|
<command>cvs commit</command>.</para>
|
|
|
|
<para>In modo analogo, puoi aggiungere nuove directory creandole e poi
|
|
utilizzando <command>cvs add</command> su di esse. Nota che non
|
|
c'è bisogno di usare il commit sulle directory.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Rimuovi i file obsoleti con il comando
|
|
<command>remove</command>.</para>
|
|
|
|
<para>Rimuovi il file, quindi usa <command>cvs rm</command> su di esso,
|
|
ed infine <command>cvs commit</command>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Effettua il commit con il comando <command>commit</command> o
|
|
<command>checkin</command>.</para>
|
|
|
|
<table frame="none">
|
|
<title>Opzioni utili con <command>cvs commit</command></title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry><option>-f</option></entry>
|
|
|
|
<entry>Forza il commit di un file non modificato.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><option>-m<replaceable>msg</replaceable></option></entry>
|
|
|
|
<entry>Specifica un messaggio di commit sulla riga di comando
|
|
anziché invocare un editor.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Usa l'opzione <option>-f</option> se ti accorgi che hai lasciato
|
|
fuori informazioni importanti dal messaggio di commit.</para>
|
|
|
|
<para>Buoni messaggi di commit sono importanti. Dicono agli altri
|
|
perché hai fatto le modifiche che hai fatto, non solo qui ed
|
|
ora, ma per mesi o anni quando qualcuno si chiederà
|
|
perché dei pezzi di codice all'apparenza illogici o
|
|
inefficienti sono entrati nel file sorgente. È inoltre un
|
|
aiuto inestimabile per decidere su quali modifiche va effettuato
|
|
l'MFC e su quali no.</para>
|
|
|
|
<para>I messaggi di commit devono essere chiari, concisi, e fornire
|
|
un ragionevole sommario per dare un'indicazione di cosa è stato
|
|
cambiato e perché.</para>
|
|
|
|
<para>I messaggi di commit devono fornire abbastanza informazioni
|
|
affinché una terza parte possa decidere se la modifica è
|
|
rilevante per lei e se debba leggere la modifica stessa.</para>
|
|
|
|
<para>Evita di effettuare il commit di più modifiche scollegate
|
|
in una volta sola. Questo rende difficile la fusione, e inoltre rende
|
|
più complicato determinare quale modifica è colpevole
|
|
se salta fuori un bug.</para>
|
|
|
|
<para>Evita di effettuare il commit di correzioni di stile o di
|
|
spaziatura insieme a correzioni di funzionalità. Questo rende
|
|
difficile la fusione, e inoltre rende più complicato capire
|
|
quali modifiche alle funzionalità sono state fatte. Nel caso
|
|
di file di documentazione, può rendere il lavoro dei gruppi
|
|
di traduzione più complicato, visto che diventa difficile per
|
|
loro determinare esattamente quali modifiche al contenuto vanno
|
|
tradotte.</para>
|
|
|
|
<para>Evita di effettuare il commit di cambiamenti a più file
|
|
con un unico messaggio generico o vago. Invece, effettua il commit
|
|
di un file alla volta (o di piccoli gruppi di file correlati) con un
|
|
messaggio di commit appropriato.</para>
|
|
|
|
<para>Prima di effettuare il commit, devi
|
|
<emphasis>sempre</emphasis>:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>verificare su che ramo stai effettuando il commit, tramite
|
|
<command>cvs status</command>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>revisionare i tuoi cambiamenti, con
|
|
<command>cvs diff</command></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Inoltre, devi SEMPRE specificare esplicitamente sulla riga di
|
|
comando su quali file deve essere effettuato il commit, in modo da non
|
|
toccare incidentalmente altri file non voluti - <command>cvs
|
|
commit</command> senza argomenti effettuerà il commit di ogni
|
|
modifica nella directory corrente ed ogni sottodirectory.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Suggerimenti e trucchi aggiuntivi:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Puoi inserire le opzioni più comunemente usate nel tuo
|
|
<filename>~/.cvsrc</filename>, come in questo caso:</para>
|
|
|
|
<programlisting>cvs -z3
|
|
diff -Nu
|
|
update -Pd
|
|
checkout -P</programlisting>
|
|
|
|
<para>Questo esempio dice:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>usa sempre il livello di compressione 3 quando si parla con un
|
|
server remoto. Questo è un salvavita quando si lavora su
|
|
una connessione lenta.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>usa sempre le opzioni <option>-N</option> (visualizza i file
|
|
aggiunti o rimossi) e <option>-u</option> (formato diff unificato)
|
|
con &man.diff.1;.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>usa sempre le opzioni <option>-P</option> (elimina le
|
|
directory vuote) e <option>-d</option> (estrai le nuove directory)
|
|
quando si effettua l'update.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>usa sempre l'opzione <option>-P</option> (elimina le
|
|
directory vuote) quando si estrae.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Usa lo script <command>cdiff</command> di Eivind Eklund per
|
|
visualizzare le diff unificate. È un wrapper per &man.less.1;
|
|
che aggiunge i codici colore ANSI per far risaltare le intestazioni
|
|
delle sezioni, le righe rimosse e quelle aggiunte; il contesto rimane
|
|
invariato. Inoltre espande i tab correttamente (i tab spesso appaiono
|
|
errati nelle diff a causa del carattere aggiuntivo all'inizio di ogni
|
|
riga).</para>
|
|
|
|
<para><filename role="package">textproc/cdiff</filename></para>
|
|
|
|
<para>Semplicemente usalo al posto di &man.more.1; o
|
|
&man.less.1;:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs diff -Nu shazam | cdiff</userinput></screen>
|
|
|
|
<para>Alternativamente alcuni editor come &man.vim.1;
|
|
(<filename role="package">editors/vim5</filename>) hanno il supporto
|
|
al colore e quando vengono usati con l'evidenziazione della sintassi
|
|
attiva evidenzieranno molti tipi di file, incluse le diff, le patch,
|
|
e i log CVS/RCS.</para>
|
|
|
|
<screen>&prompt.user; <userinput>echo "syn on" >> ~/.vimrc </userinput>
|
|
&prompt.user; <userinput>cvs diff -Nu shazam | vim -</userinput>
|
|
&prompt.user; <userinput>cvs log shazam | vim -</userinput> </screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>CVS è vecchio, arcano, complesso e buggato, e a volte
|
|
esibisce comportamenti non deterministici che qualcuno sostiene siano
|
|
la prova che CVS non sia niente di più di una manifestazione
|
|
Newtoniana di una entità ultradimensionale sensibile.
|
|
Non è umanamente possibile conoscere ogni dettaglio di CVS,
|
|
quindi non essere dispiaciuto di chiedere aiuto all'Intelligenza
|
|
Artificiale (&a.cvsadm;).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Non lasciare il comando <command>cvs commit</command> nella
|
|
modalità di inserimento del messaggio di commit per troppo
|
|
tempo (più di 2–3 minuti). Questo blocca la directory in
|
|
cui stai lavorando ed impedirà ad altri sviluppatori di
|
|
effettuare commit nella stessa directory. Se devi digitare un
|
|
messaggio di commit lungo, scrivilo prima di eseguire
|
|
<command>cvs commit</command> e inseriscilo successivamente oppure
|
|
salvalo in un file prima di effettuare il commit ed usa l'opzione
|
|
<option>-F</option> di CVS per leggere il messaggio di commit da
|
|
quel file, cioè:</para>
|
|
|
|
<screen>&prompt.user; <userinput>vi logmsg</userinput>
|
|
&prompt.user; <userinput>cvs ci -F logmsg shazam</userinput></screen>
|
|
|
|
<para>Questo è il metodo più veloce per passare un
|
|
messaggio di commit a CVS ma devi stare attento quando modifichi
|
|
il file <filename>logmsg</filename> prima del commit, perché
|
|
CVS non ti darà la possibilità di modificare il
|
|
messaggio quando effettuerai realmente il commit.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="conventions">
|
|
<title>Convenzioni e Tradizioni</title>
|
|
|
|
<para>Come nuovo committer ci sono alcune cose che dovresti fare
|
|
all'inizio.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Aggiungi la tua entity di autore in
|
|
<filename>doc/en_US.ISO8859-1/share/xml/authors.ent</filename>;
|
|
questo dovrebbe essere fatto per prima cosa, visto che l'omissione
|
|
di questo commit farà in modo che i prossimi commit
|
|
romperanno la compilazione del ramo doc/.</para>
|
|
|
|
<para>Questo è un compito relativamente semplice, ma rimane una
|
|
buona prima prova delle tue abilità con CVS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Aggiungi te stesso alla sezione <quote>Developers</quote> della
|
|
<ulink url="&url.articles.contributors.en;/index.html">Contributors
|
|
List</ulink> e
|
|
rimuovere te stesso dalla sezione <quote>Additional
|
|
Contributors</quote>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Aggiungi una voce per te stesso in
|
|
<filename>www/en/news/news.xml</filename>. Guarda le altre voci che
|
|
assomigliano a <quote>A new committer</quote> e segui il
|
|
formato.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Dovresti aggiungere la tua chiave PGP o GnuPG in
|
|
<filename>doc/share/pgpkeys</filename> (e se non ce l'hai, dovresti
|
|
creartene una). Non dimenticare di effettuare il commit del file
|
|
<filename>doc/share/pgpkeys/pgpkeys.ent</filename> aggiornato.</para>
|
|
|
|
<para>&a.des; ha scritto uno script di shell per rendere questa
|
|
operazione molto semplice. Guarda il file <ulink
|
|
url="http://cvsweb.FreeBSD.org/doc/share/pgpkeys/README">README</ulink>
|
|
per maggiori informazioni.</para>
|
|
|
|
<note>
|
|
<para>È importante avere una chiave PGP/GnuPG aggiornata nel
|
|
Manuale, visto che potrà essere richiesta per
|
|
l'identificazione del committer, ad esempio dai &a.admins; per
|
|
il recupero dell'account. Un portachiavi completo degli utenti
|
|
<hostid role="domainname">FreeBSD.org</hostid> è disponibile
|
|
su <ulink
|
|
url="&url.base;/doc/pgpkeyring.txt">http://www.FreeBSD.org/doc/pgpkeyring.txt</ulink>.</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Alcune persone aggiungono una voce per se stessi in
|
|
<filename>ports/astro/xearth/files/freebsd.committers.markers</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Alcune persone aggiungono una voce per se stessi in
|
|
<filename>src/usr.bin/calendar/calendars/calendar.freebsd</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Presentati agli altri committer, altrimenti nessuno avrà
|
|
idea di chi tu sia o di cosa ti occupi. Non devi scrivere una
|
|
biografia completa, basta un paragrafo o due su chi sei e su quello
|
|
di cui hai intenzione di occuparti come committer di FreeBSD.
|
|
Invialo alla &a.developers; e sarai sulla strada giusta!</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Loggati su <hostid>hub.FreeBSD.org</hostid> e crea un file
|
|
<filename>/var/forward/<replaceable>utente</replaceable></filename>
|
|
(dove <replaceable>utente</replaceable> è il tuo nome utente)
|
|
contenente l'indirizzo e-mail dove vuoi che i messaggi indirizzati a
|
|
<replaceable>tuonomeutente</replaceable>@FreeBSD.org siano inoltrati.
|
|
Questo include tutti i messaggi di commit così come ogni altro
|
|
messaggio inviato alla &a.committers; e alla &a.developers;. Caselle
|
|
di posta veramente grandi che hanno preso residenza fissa su
|
|
<hostid>hub</hostid> spesso vengono <quote>accidentalmente</quote>
|
|
troncate senza preavviso, quindi inoltra o leggi i messaggi in modo da
|
|
non perderli.</para>
|
|
|
|
<para>A causa dell'intenso carico per la gestione dello SPAM che
|
|
arriva ai server di posta centrali che processano le mailing list, i
|
|
server front-end fanno alcuni controlli e non fanno passare alcuni
|
|
messaggi in base a questi controlli. Al momento l'unico controllo
|
|
attivo è la verifica sulla correttezza delle informazioni DNS
|
|
dell'host che si connette, ma questo potrebbe cambiare. Alcune
|
|
persone accusano questi controlli di respingere email valide. Se
|
|
vuoi disabilitare questi controlli per la tua email puoi creare
|
|
un file chiamato <filename>~/.spam_lover</filename> nella tua
|
|
directory home su <hostid
|
|
role="fqdn">freefall.FreeBSD.org</hostid>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Se sei iscritto alla &a.cvsall;, probabilmente vorrai
|
|
disiscriverti per evitare di ricevere copie doppie dei messaggi di
|
|
commit e della loro evoluzione.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Tutti i nuovi committer hanno un mentore assegnato a loro per i primi
|
|
mesi. Il tuo mentore è responsabile di insegnarti le regole e le
|
|
convenzioni del progetto e guidare i tuoi primi passi nella
|
|
comunità dei committer. È anche personalmente responsabile
|
|
delle tue azioni durante questo periodo iniziale. Fino a quando il tuo
|
|
mentore non decide (e lo annuncia con un commit forzato su
|
|
<filename>access</filename>) che sei diventato pratico e pronto per
|
|
effettuare commit da solo, non dovresti effettuare commit senza aver
|
|
prima ottenuto la revisione e l'approvazione del tuo mentore, e dovresti
|
|
documentare l'approvazione con una riga <literal>Approved by:</literal>
|
|
nel messaggio di commit.</para>
|
|
|
|
<para>Tutti i commit <filename>src</filename> dovrebbero andare
|
|
su &os.current; prima di essere
|
|
fusi in &os.stable;. Nessuna nuova caratteristica importante o modifica
|
|
ad alto rischio dovrebbe essere fatta sul ramo &os.stable;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="pref-license">
|
|
<title>Licenza Preferita per i Nuovi File</title>
|
|
|
|
<para>Attualmente il &os; Project suggerisce di usare il seguente testo
|
|
come schema di licenza preferito:</para>
|
|
|
|
<programlisting>Copyright © <Year> <Author>. All rights reserved.
|
|
|
|
Redistribution and use in source and binary forms, with or without
|
|
modification, are permitted provided that the following conditions
|
|
are met:
|
|
1. Redistributions of source code must retain the above copyright
|
|
notice, this list of conditions and the following disclaimer.
|
|
2. Redistributions in binary form must reproduce the above copyright
|
|
notice, this list of conditions and the following disclaimer in the
|
|
documentation and/or other materials provided with the distribution.
|
|
|
|
THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
SUCH DAMAGE.</programlisting>
|
|
|
|
<para>Il progetto &os; scoraggia fortemente la cosiddetta clausola
|
|
pubblicitaria nel nuovo codice. A causa del grande numero di
|
|
contributi al progetto &os;, osservare questa clausola per molti
|
|
fornitori commerciali è diventato difficile. Se hai codice
|
|
nell'albero con la clausola pubblicitaria, pensa a rimuoverla.
|
|
In pratica, considera di usare la licenza qui sopra per il tuo
|
|
codice.</para>
|
|
|
|
<para>Il progetto &os; scoraggia completamente nuove licenze e variazioni
|
|
sulle licenze standard. Nuove licenze richiedono l'approvazione di
|
|
<email>core@FreeBSD.org</email> per risiedere nel repository principale.
|
|
Più licenze differenti vengono usate nell'albero, più
|
|
problemi possono essere causati a chi desidera utilizzare questo codice,
|
|
tipicamente da conseguenze non previste di una licenza strutturata
|
|
male.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="developer.relations">
|
|
<title>Relazioni tra Sviluppatori</title>
|
|
|
|
<para>Se stai lavorando direttamente sul tuo codice o su codice che è
|
|
già stabilito essere di tua responsabilità, allora
|
|
c'è probabilmente poca necessità di confrontarsi con altri
|
|
committer prima di effettuare un commit. Se vedi un bug in un'area del
|
|
sistema che è chiaramente orfana (e ce n'è qualcuna di
|
|
queste aree, per nostra vergogna), agisci allo stesso modo. Se, tuttavia,
|
|
stai per modificare qualcosa che è chiaramente mantenuto
|
|
attivamente da qualcun'altro (ed è solo guardando la mailing list
|
|
<literal>cvs-committers</literal> che puoi veramente sapere cosa è
|
|
e cosa non è) allora invia le modifiche a lui, come avresti
|
|
fatto prima di diventare committer. Per i port, dovresti contattare il
|
|
<makevar>MAINTAINER</makevar> specificato nel
|
|
<filename>Makefile</filename>. Per altre parti del repository, se non sei
|
|
sicuro di chi possa essere il maintainer attivo, potrebbe essere utile
|
|
scorrere l'output di <command>cvs log</command> per vedere chi ha
|
|
effettuato delle modifiche in passato. &a.fenner; ha scritto un utile
|
|
script di shell che può aiutare a determinare chi sia il
|
|
maintainer attivo. Questo elenca ogni persona che ha effettuato commit
|
|
su un file specifico con il numero di commit che ha fatto. Può
|
|
essere trovato su <hostid>freefall</hostid> in
|
|
<filename>~fenner/bin/whodid</filename>. Se alle tue richieste non
|
|
corrisponde una risposta o se il committer in altro modo dimostra uno
|
|
scarso interesse nell'area oggetto della modifica, vai avanti ed effettua
|
|
il commit tu stesso.</para>
|
|
|
|
<para>Se non sei sicuro di un commit per qualunque motivo, fallo revisionare
|
|
da <literal>-hackers</literal> prima di effettuare il commit. Meglio
|
|
che sia criticato lì piuttosto che quando è parte del
|
|
repository CVS. Se ti capita di effettuare un commit che provoca
|
|
controversie, potresti voler considerare l'annullamento delle modifiche
|
|
finché il problema sia chiarito. Ricorda – con CVS possiamo
|
|
sempre tornare indietro.</para>
|
|
|
|
<para>Non mettere in dubbio le intenzioni di qualcuno che non è
|
|
d'accordo con te. Se vedono una soluzione differente dalla tua per un
|
|
problema, o anche un problema diverso, non è perché sono
|
|
stupidi, perché hanno una dubbia origine, o perché stanno
|
|
cercando di distruggere il tuo duro lavoro, la tua immagine personale, o
|
|
FreeBSD, ma semplicemente perché hanno una visione differente del
|
|
mondo. La diversità è una buona cosa.</para>
|
|
|
|
<para>Dissenti onestamente. Argomenta la tua posizione con i suoi meriti,
|
|
sii onesto sui difetti che può avere, e sii disponibile a guardare
|
|
le loro soluzioni, o anche le loro visioni del problema, con mente
|
|
aperta.</para>
|
|
|
|
<para>Accetta le correzioni. Possiamo tutti sbagliare. Se hai fatto un
|
|
errore, scusati e vai avanti con la tua vita. Non picchiarti, e
|
|
sicuramente non picchiare gli altri per il tuo sbaglio. Non sprecare
|
|
tempo imbarazzandoti o recriminando, risolvi solo il problema e vai
|
|
avanti.</para>
|
|
|
|
<para>Chiedi aiuto. Cerca (e dai) revisioni dagli altri. Uno delle cose
|
|
in cui dovrebbe eccellere il software open source è il numero di
|
|
occhi che lo scrutano; questo non è vero se nessuno
|
|
revisionerà il codice.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="gnats">
|
|
<title>GNATS</title>
|
|
|
|
<para>Il FreeBSD Project utilizza <application>GNATS</application> per
|
|
gestire i bug e le richieste di cambiamenti. Assicurati di usare
|
|
<command>edit-pr <replaceable>numero-pr</replaceable></command> su
|
|
<hostid>freefall</hostid> quando effettui il commit di una correzione o di
|
|
un suggerimento trovato in un PR <application>GNATS</application> per
|
|
chiuderlo. È inoltre considerato gentile se trovi il tempo di
|
|
chiudere ogni PR associato al tuo commit, se esistono. Puoi anche usare
|
|
&man.send-pr.1; tu stesso per proporre qualsiasi cambiamento che pensi
|
|
debba essere fatto, a seguito di una maggiore revisione da parte di altre
|
|
persone.</para>
|
|
|
|
<para>Puoi trovare di più su <application>GNATS</application>
|
|
su:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><ulink
|
|
url="http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html">http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><ulink
|
|
url="&url.base;/support.html">http://www.FreeBSD.org/support.html</ulink></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>&man.send-pr.1;</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Puoi far girare una copia locale di GNATS, e poi integrare l'albero
|
|
GNATS di FreeBSD in esso tramite CVSup. In seguito puoi usare i comandi
|
|
GNATS localmente, o usare altre interfacce, come
|
|
<command>tkgnats</command>. Questo ti permette di interrogare il database
|
|
dei PR senza bisogno di essere connesso a Internet.</para>
|
|
|
|
<procedure>
|
|
<title>Utilizzo di un albero GNATS locale</title>
|
|
|
|
<step>
|
|
<para>Se non stai già scaricando l'albero GNATS, aggiungi questa
|
|
riga al tuo <filename>supfile</filename>, e riesegui &man.cvsup.1;.
|
|
Nota che siccome GNATS non è sotto
|
|
il controllo di CVS non ha tag, quindi se lo stai aggiungendo al tuo
|
|
<filename>supfile</filename> esistente deve apparire prima di ogni
|
|
voce <quote>tag=</quote> dato che queste rimangono attive una volta
|
|
impostate.</para>
|
|
|
|
<programlisting>gnats release=current prefix=/usr</programlisting>
|
|
|
|
<para>Questo metterà l'albero GNATS di FreeBSD in
|
|
<filename>/usr/gnats</filename>. Puoi usare un file
|
|
<emphasis>refuse</emphasis> per controllare quali categorie ricevere.
|
|
Per esempio, per ricevere solo i PR <literal>docs</literal>, metti
|
|
questa riga in <filename>/usr/local/etc/cvsup/sup/refuse</filename>
|
|
<footnote>
|
|
<para>Il percorso preciso dipende dall'impostazione
|
|
<literal>*default base</literal> nel tuo
|
|
<filename>supfile</filename>.</para>
|
|
</footnote>.</para>
|
|
|
|
<programlisting>gnats/[a-ce-z]*</programlisting>
|
|
|
|
<para>Il resto di questi esempi assume che tu abbia scaricato solo la
|
|
categoria <literal>docs</literal>. Modificali quando è
|
|
necessario, a seconda delle categorie che tieni in sincronia.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Installa il port GNATS da
|
|
<filename>ports/databases/gnats</filename>. Questo metterà le
|
|
varie directory GNATS sotto
|
|
<filename>$PREFIX/share/gnats</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Crea un symlink per le directory GNATS che aggiorni tramite CVSup
|
|
sotto la versione di GNATS che hai installato.</para>
|
|
|
|
<screen>&prompt.root; <userinput>cd /usr/local/share/gnats/gnats-db</userinput>
|
|
&prompt.root; <userinput>ln -s /usr/gnats/docs</userinput></screen>
|
|
|
|
<para>Ripeti tante volte quanto necessario, a seconda di quante
|
|
categorie GNATS tieni in sincronia.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Aggiorna il file <filename>categories</filename> di GNATS con
|
|
queste categorie. Il file è
|
|
<filename>$PREFIX/share/gnats/gnats-db/gnats-adm/categories</filename>.</para>
|
|
|
|
<programlisting># Questa categoria è obbligatoria
|
|
pending:Categoria per i PR errati:gnats-admin:
|
|
#
|
|
# Categorie di FreeBSD
|
|
#
|
|
docs:Bug di Documentazione:freebsd-doc:</programlisting>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Esegui <filename>$PREFIX/libexec/gnats/gen-index</filename> per
|
|
ricreare l'indice GNATS. L'output deve essere reindirizzato su
|
|
<filename>$PREFIX/share/gnats/gnats-db/gnats-adm/index</filename>.
|
|
Puoi fare questo periodicamente da &man.cron.8;, o eseguire
|
|
&man.cvsup.1; da uno script di shell che fa anche questo.</para>
|
|
|
|
<screen>&prompt.root; <userinput>/usr/local/libexec/gnats/gen-index \
|
|
> /usr/local/share/gnats/gnats-db/gnats-adm/index</userinput></screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Verifica la configurazione interrogando il database dei PR.
|
|
Questo comando visualizza i PR <literal>docs</literal> aperti.</para>
|
|
|
|
<screen>&prompt.root; <userinput>query-pr -c docs -s open</userinput></screen>
|
|
|
|
<para>Anche altre interfacce, come quella fornita dal port <filename
|
|
role="package">databases/tkgnats</filename>, dovrebbero funzionare
|
|
correttamente.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Prendi un PR e chiudilo.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<note>
|
|
<para>Questa procedura funziona solo per permetterti di visualizzare ed
|
|
interrogare i PR localmente. Per modificarli o chiuderli dovrai ancora
|
|
loggarti su <hostid>freefall</hostid> e farlo da lì.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="people">
|
|
<title>Chi è Chi</title>
|
|
|
|
<para>Oltre ai meister del repository, ci sono altri membri e team del
|
|
FreeBSD Project che probabilmente arriverai a conoscere nel tuo ruolo di
|
|
committer. Brevemente, e senza pretesa di elencarli tutti, questi
|
|
sono:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>&a.jhb;</term>
|
|
|
|
<listitem>
|
|
<para>John è il manager dell'SMPng Project, e ha
|
|
autorità sulla progettazione architetturale e
|
|
sull'implementazione del passaggio a un sistema di threading e
|
|
locking del kernel a grana fine. È anche l'autore
|
|
dell'SMPng Architecture Document. Se stai lavorando sullo stesso
|
|
sistema, coordinati con John.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.jake;, &a.tmm;</term>
|
|
|
|
<listitem>
|
|
<para>Jake e Thomas sono i maintainer del port sull'architettura
|
|
&sparc64;.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.doceng;</term>
|
|
|
|
<listitem>
|
|
<para>doceng è il gruppo responsabile dell'infrastruttura
|
|
per la realizzazione della documentazione, approva i nuovi committer
|
|
della documentazione, e assicura che il sito web di FreeBSD e la
|
|
documentazione sul sito FTP siano aggiornati rispetto all'albero
|
|
CVS. Non è un organo di risoluzione dei conflitti.
|
|
La maggior parte delle discussioni relative alla documentazione
|
|
prendono posto sulla &a.doc;. Maggiori dettagli riguardanti il
|
|
team doceng possono essere trovati nel suo <ulink
|
|
url="http://www.FreeBSD.org/internal/doceng.html">statuto</ulink>.
|
|
I committer interessati a contribuire
|
|
alla documentazione dovrebbero familiarizzare con il <ulink
|
|
url="&url.books.fdp-primer.en;/index.html">Documentation
|
|
Project Primer</ulink>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.ru;</term>
|
|
|
|
<listitem>
|
|
<para>Ruslan è Mister &man.mdoc.7;. Se stai scrivendo una
|
|
pagina man e hai bisogno di qualche suggerimento sulla struttura,
|
|
o sul linguaggio di markup, chiedi a Ruslan.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.bde;</term>
|
|
|
|
<listitem>
|
|
<para>Bruce è lo Style Police-Meister. Quando fai un commit
|
|
che poteva essere fatto meglio, Bruce sarà lì a
|
|
dirtelo. Ringrazia che qualcuno lo sia. Bruce conosce anche molto
|
|
bene gli standard applicabili a FreeBSD.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.gallatin;</term>
|
|
<term>&a.mjacob;</term>
|
|
<term>&a.dfr;</term>
|
|
<term>&a.obrien;</term>
|
|
|
|
<listitem>
|
|
<para>Questi sono gli sviluppatori e i supervisori primari della
|
|
piattaforma DEC Alpha AXP.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.dg;</term>
|
|
|
|
<listitem>
|
|
<para>David è il supervisore del sistema VM. Se hai in mente
|
|
una modifica al sistema VM, coordinala con David.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.dfr;</term>
|
|
<term>&a.marcel;</term>
|
|
<term>&a.peter;</term>
|
|
<term>&a.ps;</term>
|
|
|
|
<listitem>
|
|
<para>Questi sono i principali sviluppatori e supervisori della
|
|
piattaforma Intel IA-64, ufficialmente conosciuta come l'&itanium;
|
|
Processor Family (IPF).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.murray;</term>
|
|
<term>&a.steve;</term>
|
|
<term>&a.rwatson;</term>
|
|
<term>&a.jhb;</term>
|
|
<term>&a.scottl;</term>
|
|
<term>&a.kensmith;</term>
|
|
<term>&a.hrs;</term>
|
|
|
|
<listitem>
|
|
<para>Questi sono i membri del &a.re;. Questo team è
|
|
responsabile di decidere i tempi delle release e controllare il
|
|
processo di release. Durante i periodi di congelamento del
|
|
codice, gli ingegneri di release hanno l'autorità finale su
|
|
tutte le modifiche al sistema per quel ramo di cui si sta preparando
|
|
la release. Se c'è qualcosa che vuoi sia fuso da
|
|
&os.current; a &os.stable; (qualsiasi valore queste possano avere
|
|
in un dato momento), queste sono le persone con cui devi
|
|
parlare.</para>
|
|
|
|
<para>Hiroki è anche l'autore della documentazione di
|
|
release (<filename>src/release/doc/*</filename>). Se effettui il
|
|
commit di una modifica che pensi sia degna di menzione nelle note
|
|
di release, assicurati che lo sappia. Meglio ancora, inviagli
|
|
una patch con il tuo commento.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.benno;</term>
|
|
|
|
<listitem>
|
|
<para>Benno è il maintainer ufficiale del port per
|
|
&powerpc;.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.brian;</term>
|
|
|
|
<listitem>
|
|
<para>Maintainer ufficiale di
|
|
<filename>/usr/sbin/ppp</filename>.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.nectar;</term>
|
|
|
|
<listitem>
|
|
<para>Jacques è il <ulink url="&url.base;/security/">FreeBSD
|
|
Security Officer</ulink> e supervisiona il
|
|
&a.security-officer;.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.wollman;</term>
|
|
|
|
<listitem>
|
|
<para>Se hai bisogno di consigli sulle oscure parti interne delle reti
|
|
o non sei sicuro di qualche eventuale modifica al sottosistema di
|
|
rete che hai in mente, Garrett è qualcuno con cui parlare.
|
|
Garret è inoltre molto esperto sui vari standard applicabili
|
|
a FreeBSD.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.committers;</term>
|
|
|
|
<listitem>
|
|
<para>cvs-committers è l'entità che CVS usa per inviarti
|
|
tutti i messaggi di commit. Non devi <emphasis>mai</emphasis>
|
|
inviare email direttamente a questa lista. Puoi solamente
|
|
rispondere a questa lista quando i messaggi sono brevi e
|
|
direttamente correlati a un commit.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>&a.developers;</term>
|
|
|
|
<listitem>
|
|
<para>Tutti i committer sono iscritti a -developers. Questa lista
|
|
è stata creata per essere un forum sulle questioni della
|
|
<quote>comunità</quote> dei committer. Esempi sono le
|
|
votazioni per il Core, annunci, ecc. Questa lista
|
|
<emphasis>non</emphasis> è intesa come posto per la revisione
|
|
del codice o come rimpiazzo della &a.arch; o della &a.audit;.
|
|
Infatti usarla in questo modo urta il FreeBSD Project dato che
|
|
dà l'impressione di una lista privata dove vengono prese le
|
|
decisioni generali che influenzano tutta la comunità che usa
|
|
FreeBSD senza essere rese <quote>pubbliche</quote>.
|
|
Ultimo, ma non per importanza <emphasis>mai e poi mai invia un
|
|
messaggio alla &a.developers; mettendo in CC:/BCC: un'altra lista
|
|
FreeBSD</emphasis>.
|
|
Mai e poi mai invia un messaggio su un'altra mailing list mettendo
|
|
in CC:/BCC: la &a.developers;. Fare questo può diminuire
|
|
enormemente i benefici di questa lista. Inoltre, non pubblicare o
|
|
inoltrare mai email inviate alla &a.developers;. L'atto di inviare
|
|
un messaggio alla &a.developers; anziché a una lista
|
|
pubblica significa che le informazioni contenute non sono ad uso
|
|
pubblico.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect1>
|
|
|
|
<sect1 id="ssh.guide">
|
|
<title>Guida Rapida a SSH</title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Se stai usando FreeBSD 4.0 o successivo, OpenSSH è incluso
|
|
nel sistema base. Se stai usando una release precedente, aggiorna
|
|
ed installa uno dei port di SSH. In generale, probabilmente vorrai
|
|
prendere OpenSSH dal port <filename
|
|
role="package">security/openssh</filename>. Potresti anche voler
|
|
estrarre l'ssh1 originale dal port <filename
|
|
role="package">security/ssh</filename>, ma sii certo di porre la
|
|
dovuta attenzione alla sua licenza. Nota che questi port non possono
|
|
essere installati contemporaneamente.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Se non vuoi digitare la tua password ogni volta che usi
|
|
&man.ssh.1;, e usi chiavi RSA o DSA per autenticarti,
|
|
&man.ssh-agent.1; è lì per la tua comodità.
|
|
Se vuoi usare &man.ssh-agent.1;, assicurati di eseguirlo prima di
|
|
utilizzare altre applicazioni. Gli utenti X, per esempio, solitamente
|
|
fanno questo dal loro file <filename>.xsession</filename> o
|
|
<filename>.xinitrc</filename>. Guarda &man.ssh-agent.1; per i
|
|
dettagli.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Genera un paio di chiavi con &man.ssh-keygen.1;. Le chiavi
|
|
finiranno nella tua directory
|
|
<filename><envar>$HOME</envar>/.ssh/</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Invia la tua chiave pubblica
|
|
(<filename><envar>$HOME</envar>/.ssh/id_dsa.pub</filename> o
|
|
<filename><envar>$HOME</envar>/.ssh/id_rsa.pub</filename>)
|
|
alla persona che ti sta configurando come committer in modo che possa
|
|
inserirla nel file
|
|
<filename><replaceable>tualogin</replaceable></filename> su
|
|
<hostid>freefall</hostid>.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>Ora dovresti essere in grado di usare &man.ssh-add.1; per autenticarti
|
|
una volta a sessione. Ti verrà richiesta la pass phrase della tua
|
|
chiave privata, e quindi verrà salvata nel tuo agente di
|
|
autenticazione (&man.ssh-agent.1;). Se non vuoi più avere la tua
|
|
chiave salvata nell'agente, l'esecuzione di <command>ssh-add -d</command>
|
|
la rimuoverà.</para>
|
|
|
|
<para>Verifica facendo qualcosa come <command>ssh freefall.FreeBSD.org ls
|
|
/usr</command>.</para>
|
|
|
|
<para>Per maggiori informazioni, guarda <filename
|
|
role="package">security/openssh</filename>, &man.ssh.1;,
|
|
&man.ssh-add.1;, &man.ssh-agent.1;, &man.ssh-keygen.1;, e
|
|
&man.scp.1;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="rules">
|
|
<title>Il Lungo Elenco di Regole dei Committer di FreeBSD</title>
|
|
|
|
<para>Traduzione in corso</para>
|
|
</sect1>
|
|
|
|
<sect1 id="archs">
|
|
<title>Supporto per Diverse Architetture</title>
|
|
|
|
<para>Traduzione in corso</para>
|
|
</sect1>
|
|
|
|
<sect1 id="ports">
|
|
<title>FAQ Specifiche sui Port</title>
|
|
|
|
<para>Traduzione in corso</para>
|
|
</sect1>
|
|
|
|
<sect1 id="perks">
|
|
<title>Benefici del Lavoro</title>
|
|
|
|
<para>Sfortunatamente, non ci sono molti benefici derivanti dall'essere un
|
|
committer. Il riconoscimento di essere un progettista di software
|
|
competente è probabilmente l'unica cosa che sarà di tuo
|
|
vantaggio a lungo termine. Ciononostante, ci sono comunque alcuni
|
|
benefici:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Accesso diretto al <hostid>cvsup-master</hostid></term>
|
|
|
|
<listitem>
|
|
<para>Come committer, puoi chiedere a &a.kuriyama; accesso diretto
|
|
a <hostid role="fqdn">cvsup-master.FreeBSD.org</hostid>,
|
|
fornendo l'output della tua chiave pubblica tramite
|
|
<command>cvpasswd
|
|
<replaceable>yourusername</replaceable>@FreeBSD.org
|
|
freefall.FreeBSD.org</command>. Nota: devi specificare
|
|
<hostid>freefall.FreeBSD.org</hostid> sulla riga di comando si
|
|
<command>cvpasswd</command> anche se il server attuale è
|
|
<hostid>cvsup-master</hostid>. L'accesso al
|
|
<hostid>cvsup-master</hostid> non dovrebbe essere abusato visto che
|
|
è una macchina carica di lavoro.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Un abbonamento gratuito al set da 4 CD o DVD</term>
|
|
|
|
<listitem>
|
|
<para><ulink url="http://www.freebsdmall.com">FreeBSD Mall,
|
|
Inc.</ulink> offre un abbonamento gratuito al set da 4 CD o DVD a
|
|
tutti i committer di FreeBSD. Le informazioni su come ottenere il
|
|
prodotto gratuitamente vengono spedite a
|
|
<email>developers@FreeBSD.org</email> dopo ogni release.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect1>
|
|
|
|
<sect1 id="misc">
|
|
<title>Domande Generali</title>
|
|
|
|
<para>Traduzione in corso</para>
|
|
</sect1>
|
|
</article>
|