Notas sobre svn. Información básica para estar en condiciones de usar adecuadamente esta herramienta de aquí en más para nuestros proyectos de desarrollo.

• Version Control with Subversion: el libro online.
• SourceForge.net: Subversion (Version Control for Source Code): el documento oficial de SourceForge.

Un ejemplo de uso de svn con symfony aparece en el manual de symfony y en askeet day 1.

(Fragmentos del libro)

Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

Subversion, once installed, has a number of different pieces. The following is a quick overview of what you get. Don't be alarmed if the brief descriptions leave you scratching your head—there are plenty more pages in this book devoted to alleviating that confusion.

• svn: The command-line client program.

• svnversion: A program for reporting the state (in terms of revisions of the items present) of a working copy.

• svnlook: A tool for inspecting a Subversion repository.

• svnadmin: A tool for creating, tweaking or repairing a Subversion repository.

• svndumpfilter: A program for filtering Subversion repository dump streams.

• mod_dav_svn: A plug-in module for the Apache HTTP Server, used to make your repository available to others over a network.

• svnserve: A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network.

Para impacientes, los pasos mínimos para comenzar a usar svn ya mismo: http://svnbook.red-bean.com/en/1.2/svn.intro.quickstart.html

Estos pasos son:

• crear un nuevo repositorio (svnadmin create)
• importar los datos (e.g. el código de un proyecto) en el repositorio (svn import)
• crear una copia de trabajo del contenido del repositorio (svn checkout)
• editar, ver diferencias, enviar, actualizar (svn diff, svn commit, svn update)

The problem of file-sharing: All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

• The Lock-Modify-Unlock solution: “In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks.”

• The Copy-Modify-Merge solution (el modelo usado por Subversion, CVS y otros): “In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.” … “The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent.”

For each file in a working directory, Subversion records two essential pieces of information in the .svn/ administrative area:

• what revision your working file is based on (this is called the file's working revision), and
• a timestamp recording when the local copy was last updated by the repository.

Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:

Unchanged, and current: The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing.

Locally changed, and current: The file has been changed in the working directory, and no changes to that file have been committed to the repository since its base revision. There are local changes that have not been committed to the repository, thus an svn commit of the file will succeed in publishing your changes, and an svn update of the file will do nothing.

Unchanged, and out-of-date: The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated, to make it current with the public revision. An svn commit of the file will do nothing, and an svn update of the file will fold the latest changes into your working copy.

Locally changed, and out-of-date: The file has been changed both in the working directory, and in the repository. An svn commit of the file will fail with an “out-of-date” error. The file should be updated first; an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.

(Cómo incorporar archivos por primera vez al repositorio.)

The svn import command is a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary.

$ svnadmin create /usr/local/svn/newrepos
$ svn import mytree file:///usr/local/svn/newrepos/some/project \
             -m "Initial import"
Adding         mytree/foo.c
Adding         mytree/bar.c
Adding         mytree/subdir
Adding         mytree/subdir/quux.h

Committed revision 1.

The previous example copied the contents of directory mytree under the directory some/project in the repository:

$ svn list file:///usr/local/svn/newrepos/some/project
bar.c
foo.c
subdir/

Note that after the import is finished, the original tree is not converted into a working copy. To start working, you still need to svn checkout a fresh working copy of the tree.

Most of the time, you will start using a Subversion repository by doing a checkout of your project. Checking out a repository creates a copy of it on your local machine. This copy contains the HEAD (latest revision) of the Subversion repository that you specify on the command line:

$ svn checkout http://svn.collab.net/repos/svn/trunk
A  trunk/subversion.dsw
A  trunk/svn_check.dsp
A  trunk/COMMITTERS
A  trunk/configure.in
A  trunk/IDEAS
…
Checked out revision 2499.

Although the above example checks out the trunk directory, you can just as easily check out any deep subdirectory of a repository by specifying the subdirectory in the checkout URL:

$ svn checkout http://svn.collab.net/repos/svn/trunk/doc/book/tools
A  tools/readme-dblite.html
A  tools/fo-stylesheet.xsl
A  tools/svnbook.el
A  tools/dtd
A  tools/dtd/dblite.dtd
…
Checked out revision 2499.

Subversion has numerous features, options, bells and whistles, but on a day-to-day basis, odds are that you will only use a few of them. In this section we'll run through the most common things that you might find yourself doing with Subversion in the course of a day's work.

The typical work cycle looks like this:

• Update your working copy
  • svn update
• Make changes
  • svn add
  • svn delete
  • svn copy
  • svn move
• Examine your changes
  • svn status
  • svn diff
  • svn revert
• Merge others' changes into your working copy
  • svn update
  • svn resolved
• Commit your changes
  • svn commit

RapidSVN: cliente multiplataforma.

Primeras pruebas con el uso de svn:ignore. Algunos intentos errados.

fernando@ubuntu-fgomez:~/svn$ history | grep “svn prop”

590  svn proplist 
591  svn proplist .
593  svn proplist cgi-bin/
594  svn proplist cgi-bin/opacmarc/opac/html/bib-nav.htm 
595  svn propget svn:mime-type opacmarc-admin/opac/lang.txt 
596  svn propedit svn:ignore .
610  svn propset -R svn:ignore -F .svnignore .
614  svn propset -R svn:ignore -F .svnignore .
617  svn propdel -R svn:ignore .
622  svn propset -R svn:ignore "settings_local.py" ./django_files
628  svn propdel -R svn:ignore ./django_files
632  svn propset svn:ignore "settings_local.py" ./django_files
634  svn propset -R svn:ignore "*.pyc" ./django_files
642  svn propset svn:ignore "log-*.txt" bases/opacmarc/opac/access_logs/
645  svn propset svn:ignore "bibima/*" bases/opacmarc/opac
647  svn propset svn:ignore "bibima" bases/opacmarc/opac
649  svn propset svn:ignore "bibima" cgi-bin/opacmarc/opac/
651  svn propset -R svn:ignore "bibima" cgi-bin/opacmarc/opac/
653  svn propset -R svn:ignore "bibima*" cgi-bin/opacmarc/opac/
655  svn propset svn:ignore "local.conf" cgi-bin/opacmarc/opac/config
659  svn propset -R svn:ignore "bibima*" htdocs/opacmarc/opac/
661  svn propset svn:ignore "wxis*" cgi-bin/opacmarc
771  svn proplist catalis-dev/
772  svn proplist catalis-dev/django_files/
773  svn propget svn:ignore catalis-dev/django_files/

Los resultados de los commits están en Google Code (opacmarc y catalis).

667  svn commit -m "added local files to svn:ignore; replaced directory 'banner' with 'custom' for css customizations"
769  svn commit -m "added *.pyc to svn:ignore; added TabCloseMenu" catalis-dev/

desarrollo subversion