The first step in community participation is to find a way to stay on top of the latest happenings. To do this most effectively, you will want to subscribe to the main developer discussion list (<dev@subversion.tigris.org>) and commit mail list (<svn@subversion.tigris.org>). By following these lists even loosely, you will have access to important design discussions, be able to see actual changes to Subversion source code as they occur, and be able to witness peer reviews of those changes and proposed changes. These email based discussion lists are the primary communication media for Subversion development. See the Mailing Lists section of the website for other Subversion-related lists you might be interested in.

Il primo passo nella partecipazione alla comunità è trovare un modo per rimanere aggiornati sugli ultimi eventi. Per fare questo più efficacemente, occorrerà iscriversi alla lista di discussione principale di sviluppo (<dev@subversion.tigris.org>) e alla lista dei commit (<svn@subversion.tigris.org>). Seguendo queste liste anche approssimativamente, si ha accesso a importanti discussioni sul disegno, si possono vedere i cambiamenti effettivi al codice sorgente di Subversion quando occorrono, e si può assistere alle rassegne di questi cambiamenti e proposte di cambiamento. Queste liste di discussione basate sulle email sono il mezzo primario di comunicazione per lo sviluppo di Subversion. Vedere la sezione delle liste mail del sito web per altre liste su Subversion a cui si può essere interessati.

But how do you know what needs to be done? It is quite common for a programmer to have the greatest intentions of helping out with the development, yet be unable to find a good starting point. After all, not many folks come to the community having already decided on a particular itch they would like to scratch. But by watching the developer discussion lists, you might see mentions of existing bugs or feature requests fly by that particularly interest you. Also, a great place to look for outstanding, unclaimed tasks is the Issue Tracking database on the Subversion website. There you will find the current list of known bugs and feature requests. If you want to start with something small, look for issues marked as “bite-sized”.

Ma come si può conoscere ciò che deve essere fatto? È abbastanza comune per un programmatore avere le più grandi intenzioni di aiutare con lo sviluppo, ma non trovare un buon punto di inizio. Dopo tutto, non molta gente arriva alla comunità avendo già deciso su quale particolare rogna vorrebbero impegnarsi. Ma osservando le liste di discussione, si possono vedere menzioni di errori esistenti o richieste di caratteristiche che interessano particolarmente. Inoltre, un ottimo posto per cercare compiti eccezionali, non reclamati è il database Issue Tracking sul sito web di Subversion. Qui si troveranno la lista corrente degli errori conosciuti e delle richieste di caratteristiche. Se si vuole iniziare con qualche cosa di piccolo, cercare problemi marcati come «bite-sized».

To edit the code, you need to have the code. This means you need to check out a working copy from the public Subversion source repository. As straightforward as that might sound, the task can be slightly tricky. Because Subversion's source code is versioned using Subversion itself, you actually need to “bootstrap” by getting a working Subversion client via some other method. The most common methods include downloading the latest binary distribution (if such is available for your platform), or downloading the latest source tarball and building your own Subversion client. If you build from source, make sure to read the INSTALL file in the top level of the source tree for instructions.

Per modificare il codice, occorre avere il codice. Questo significa che occorre ottenere una copia di lavoro dal repository pubblico del sorgente di Subversion. Nonostante potrebbe suonare semplice, il compito può essere un po' complicato. Dato che il codice sorgente di Subversion è versionato utilizzando lo stesso Subversion, occorre realmente di «bootstrap» per ottenere un client di Subversion funzionante attraverso qualche altro metodo. I metodi più comuni includono lo scaricamento dell'ultima distribuzione binaria (se è disponibile per la propria piattaforma), o lo scaricamento dell'ultimo pacchetto dei sorgenti e la compilazione in proprio del client di Subversion. Se si compila dai sorgenti, assicurarsi di leggere il file INSTALL al livello più alto dell'albero dei sorgenti per istruzioni.

After you have a working Subversion client, you are now poised to checkout a working copy of the Subversion source repository from http://svn.collab.net/repos/svn/trunk/: ^[73]

Dopo che si è lavorato con il client di Subversion, you are now poised to checkout a working copy of the Subversion source repository da http://svn.collab.net/repos/svn/trunk/: ^[74]

$ svn checkout http://svn.collab.net/repos/svn/trunk subversion
A    subversion/HACKING
A    subversion/INSTALL
A    subversion/README
A    subversion/autogen.sh
A    subversion/build.conf
…

The above command will checkout the bleeding-edge, latest version of the Subversion source code into a subdirectory named subversion in your current working directory. Obviously, you can adjust that last argument as you see fit. Regardless of what you call the new working copy directory, though, after this operation completes, you will now have the Subversion source code. Of course, you will still need to fetch a few helper libraries (apr, apr-util, etc.)—see the INSTALL file in the top level of the working copy for details.

Now that you have a working copy containing the latest Subversion source code, you will most certainly want to take a cruise through the “Hacker's Guide to Subversion”, which is available either as the www/hacking.html file in the working copy, or on the Subversion website at http://subversion.tigris.org/hacking.html. This guide contains general instructions for contributing to Subversion, including how to properly format your source code for consistency with the rest of the codebase, how to describe your proposed changes with an effective change log message, how to test your changes, and so on. Commit privileges on the Subversion source repository are earned—a government by meritocracy. ^[75] The “Hacker's Guide” is an invaluable resource when it comes to making sure that your proposed changes earn the praises they deserve without being rejected on technicalities.

Ora che si ha una copia di lavoro contenente l'ultimo codice sorgente di Subversion, si vorrà molto certamente fare un giro nella «Guida dell'hacker di Subversion», che è disponibile o come file www/hacking.html nella copia di lavoro, o sul sul sito web di Subversion a http://subversion.tigris.org/hacking.html. Questa guida contiene istruzioni generali per contribuire a Subversion, incluso come formattare correttamente il proprio codice sorgente per consistenza con il resto del codice base, come descrivere le proprie proposte di cambiamento con un efficace messaggio di registro di cambiamenti, come testare i propri cambiamenti, e così via. I privilegi per fare commit sul repository dei sorgenti di Subversion vengono guadagnati— un'amministrazione di meritocrazia. ^[76] La «Guida dell'hacker» è un'inestimabile risorsa quando viene ad assicurarsi che le proprie proposte di cambiamenti guadagnano gli elogi che si meritano senza essere respinti sui tecnicismi.

With the code and community policy understanding in hand, you are ready to make your changes. It is best to try to make smaller but related sets of changes, even tackling larger tasks in stages, instead of making huge, sweeping modifications. Your proposed changes will be easier to understand (and therefore easier to review) if you disturb the fewest lines of code possible to accomplish your task properly. After making each set of proposed changes, your Subversion tree should be in a state in which the software compiles with no warnings.

Con la comprensione del codice e della politica della comunità in mano, si è pronti a fare i propri cambiamenti. È meglio provare a fare piccoli ma relativi insiemi di cambiamenti, anche intraprendere grandi compiti nelle fasi, anziché fare enormi, vaste modifiche. Le proposte di cambiamenti saranno più facili da capire (e quindi più facili da rivedere) se si disturbano il minor numero di linee di codice possibile per compiere il proprio compito correttamente. Dopo aver fatto ogni insieme di proposte di cambiamenti, il proprio albero di Subversion dovrebbe essere in uno stato in cui il software compila senza avvertimenti.

Subversion has a fairly thorough ^[77] regression test suite, and your proposed changes are expected to not cause any of those tests to fail. By running make check (in Unix) from the top of the source tree, you can sanity-check your changes. The fastest way to get your code contributions rejected (other than failing to supply a good log message) is to submit changes that cause failure in the test suite.

Subversion ha un ragionevolmente completo insieme di prove di ^[78] regressione, e le proposte di cambiamenti sono previste che non causino il fallimento di alcuna di queste prove. Eseguendo make check (in Unix) dal punto più alto dell'albero dei sorgenti, si può controllare la sanità dei propri cambiamenti. La via più veloce per vedere respinti i propri contributi al codice (oltre al non fornire un buon messaggio di registro) è presentare cambiamenti che causano il fallimenti nell'insieme delle prove.

In the best-case scenario, you will have actually added appropriate tests to that test suite which verify that your proposed changes work as expected. In fact, sometimes the best contribution a person can make is solely the addition of new tests. You can write regression tests for functionality that currently works in Subversion as a way to protect against future changes that might trigger failure in those areas. Also, you can write new tests that demonstrate known failures. For this purpose, the Subversion test suite allows you to specify that a given test is expected to fail (called an XFAIL), and so long as Subversion fails in the way that was expected, a test result of XFAIL itself is considered a success. Ultimately, the better the test suite, the less time wasted on diagnosing potentially obscure regression bugs.

Nello scenario migliore, si avrà realmente aggiunto le prove appropriate a questo insieme di prove che verifica che le proprie richieste di cambiamenti funzionino come previsto. Infatti, qualche volta il miglior contributo una persona possa fare è solamente l'aggiunta di nuove prove. Si possono scrivere prove di regressione per funzionalità che attualmente funzionano in Subversion come un modo per proteggere da futuri cambiamenti che possono innescare fallimenti in queste aree. Inoltre, si possono scrivere nuove prove che dimostrano fallimenti conosciuti. Per questo scopo, l'insieme di prove di Subversion permette di specificare che una data prova è previsto che fallisca (chiamata una XFAIL), e a condizione che Subversion fallisca nel modo che è stato previsto, il risultato di una prova di XFAIL stesso è considerato un successo. Infine, il miglior insieme di prove, il minor tempo buttato in diagnosticare potenziali oscuri errori di regressione.

After making your modifications to the source code, compose a clear and concise log message to describe those changes and the reasons for them. Then, send an email to the developers list containing your log message and the output of svn diff (from the top of your Subversion working copy). If the community members consider your changes acceptable, someone who has commit privileges (permission to make new revisions in the Subversion source repository) will add your changes to the public source code tree. Recall that permission to directly commit changes to the repository is granted on merit—if you demonstrate comprehension of Subversion, programming competency, and a “team spirit”, you will likely be awarded that permission.

Dopo aver fatto le proprie modifiche al codice sorgente, comporre un chiaro e conciso messaggio di registro per descrivere questi cambiamenti e le ragioni per cui sono stati fatti. Poi, inviare una mail alla lista degli sviluppatori contenente il proprio messaggio di registro e il risultato di svn diff (dal livello più alto della propria copia di lavoro di Subversion). Se i membri della comunità considerano i cambiamenti accettabili, qualcuno che ha i privilegi per fare il commit (permesso di fare nuove revisioni nel repository dei sorgenti di Subversion) aggiungerà i cambiamenti all'albero pubblico del codice sorgente. Ricordare che il permesso di fare il commit direttamente dei cambiamenti sul repository è concesso per meriti—se si dimostra la comprensione di Subversion, competenza di programmazione, e uno «spirito di gruppo», probabilmente si riceverà questo permesso.