There are some standard, recommended ways to organize a repository. Most people create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:

Ci sono alcuni standard, modi raccommandati per organizzare un deposito(repository). Molti creano una cartella trunk per contenere «linea principale» dello sviluppo, una cartella branches per contenere i rami e una cartella tags per contenere le targhe. Quando il deposito(repository) contiene solo un progetto, allora si creano queste cartelle di alto livello:

/trunk
/branches
/tags

If a repository contains multiple projects, admins typically index their layout by project (see sezione chiamata «Choosing a Repository Layout» to read more about “project roots”):

Quando il deposito(repository) contiene più progetti, amministratori tipicamente dividono la disposizione secondo i progetti (vedi sezione chiamata «Choosing a Repository Layout» per leggere di più riguardo «radici dei progetti»):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the svn move command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.

Of course, you're free to ignore these common layouts. You can create any sort of variation, whatever works best for you or your team. Remember that whatever you choose, it's not a permanent commitment. You can reorganize your repository at any time. Because branches and tags are ordinary directories, the svn move command can move or rename them however you wish. Switching from one layout to another is just a matter of issuing a series of server-side moves; if you don't like the way things are organized in the repository, just juggle the directories around.

Remember, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your svn move operation might remove the path from the latest revision. When the user next runs svn update, she will be told that her working copy represents a path that no longer exists, and the user will be forced to svn switch to the new location.

Ricordatevi, though, that while moving directories may be easy to do, you need to be considerate of your users as well. Your juggling can be disorienting to users with existing working copies. If a user has a working copy of a particular repository directory, your svn move operation might remove the path from the latest revision. When the user next runs svn update, she will be told that her working copy represents a path that no longer exists, and the user will be forced to svn switch to the new location.

Another nice feature of Subversion's model is that branches and tags can have finite lifetimes, just like any other versioned item. For example, suppose you eventually finish all your work on your personal branch of the calc project. After merging all of your changes back into /calc/trunk, there's no need for your private branch directory to stick around anymore:

Altra bella caratteristica del modello Subversionè che i rami e targhe hanno la vita limitata, come qualsiasi altro articolo[pezzo] versionato. Per esempio, supponiamo che avete finito lavoro su vostro ramo personale di progetto calc. Dopo fusione delle tutte vostre modifiche indietro nel /calc/trunk, non c'è più ragione per la essistenza del ramo privato:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

  $ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Rimosso ramo obsoletto del progetto calc."

  Committed revision 375.

And now your branch is gone. Of course it's not really gone: the directory is simply missing from the HEAD revision, no longer distracting anyone. If you use svn checkout, svn switch, or svn list to examine an earlier revision, you'll still be able to see your old branch.

E adesso vostro ramo è andato. Certo, in verità non è sparito: la cartella semplicemente manca nella versione HEAD, non distraendo più nessuno. Usando svn checkout, svn switch, o svn list per essaminare le versioni precedenti, potete ancora vedere vostro vecchio ramo.

If browsing your deleted directory isn't enough, you can always bring it back. Resurrecting data is very easy in Subversion. If there's a deleted directory (or file) that you'd like to bring back into HEAD, simply use svn copy -r to copy it from the old revision:

Se non vi basta navigare nella cartella cancellata, potete sempre richiamarla dietro. Risurrezione dei dati è in Subversion molto semplice. If there's a deleted directory (or file) that you'd like to bring back into HEAD, simply use svn copy -r to copy it from the old revision:

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/my-calc-branch

Committed revision 376.

In our example, your personal branch had a relatively short lifetime: you may have created it to fix a bug or implement a new feature. When your task is done, so is the branch. In software development, though, it's also common to have two “main” branches running side-by-side for very long periods. For example, suppose it's time to release a stable version of the calc project to the public, and you know it's going to take a couple of months to shake bugs out of the software. You don't want people to add new features to the project, but you don't want to tell all developers to stop programming either. So instead, you create a “stable” branch of the software that won't change much:

Nel nostro esempio, vostro ramo personale aveva la vita relativamente breve: lo avete creato per bug fix o sviluppo d'una nuova caratteristica. Quando vostro lavoro era fatto, era finito anche il ramo. Nello sviluppo di software, invece, è comune di avere due «principali» rami affiancati per lungo periodo di tempo. Per esempio, supponiamo che è giunta ora di rilasciare la versione stabile di progetto calc al pubblico, e voi sapete che ci vorrà qualche mese per cacciare via dal software gli errori. Non volete che la gente aggiunga nuove caratteristiche al progetto, ma non volete neanche fermare gli sviluppatori. Allora, create un ramo«stable» del software che non cambierà molto:

$ svn copy http://svn.example.com/repos/calc/trunk \
         http://svn.example.com/repos/calc/branches/stable-1.0 \
         -m "Creating stable branch of calc project."

Committed revision 377.

  $ svn copy http://svn.example.com/repos/calc/trunk \
  http://svn.example.com/repos/calc/branches/stable-1.0 \
  -m "Creato ramo stabile del progetto calc."

  Committed revision 377.

And now developers are free to continue adding cutting-edge (or experimental) features to /calc/trunk, and you can declare a project policy that only bug fixes are to be committed to /calc/branches/stable-1.0. That is, as people continue to work on the trunk, a human selectively ports bug fixes over to the stable branch. Even after the stable branch has shipped, you'll probably continue to maintain the branch for a long time—that is, as long as you continue to support that release for customers.

Adesso gli sviluppatori sono liberi di continuare ad aggiungere caratteristiche all'avanguardia (o sperimentali) al /calc/trunk, e voi potete stabilire la regola del progetto che solo i bug fix possono essere pubblicati nel /calc/branches/stable-1.0. Proprio così, mentre continua il lavoro sul tronco, qualcuno a mano porta selettivamente i bug fix sul ramo stabile. Anche dopo la uscita del ramo stabile al pubblico, probabilmente continuerete mantenere il ramo per lungo tempo—finché continuerà il supporto di questa versione per i clienti.