Guía rápida de subversion

  • 3 Oct 2013
  • subversion

Crear un repo

mkdir /var/www/svn
svnadmin create /var/www/svn repos

Primer import

mkdir /path/to/projectname/trunk
mkdir /path/to/projectname/branches
mkdir /path/to/projectname/tags
svn import -m "First import" /path/to/projectname https://svn.mydev.local/

Backup / Restore

svnadmin dump /path/to/reponame > /path/to/reponame.dump
svnadmin load /path/to/reponame < /path/to/reponame.dump

Trabajar con versiones

De: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

Here's where version control can help. The typical procedure looks like this:

  1. Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.
  2. The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/1.0.
  3. Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release.
  4. The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.
  5. The branch is maintained over time. While work continues on /trunk for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0. When enough bug fixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.

Un buen ejemplo: http://svnview.digium.com/svn/asterisk

Mi primer branch

svn copy https://svn.mydev.local/project-name/trunk/ https://svn.mydev.local/project-name/branches/1.0 -m "Create 1.0 branch"

Del trunk al branch

El proyecto creció más de lo pensado y el ambiente productivo que usaba el código del trunk, nos gustaría que ahora use el del branch

svn switch https://svn.mydev.local/project-name/branches/1.0/www .

El trunk cambia. El branch mejora. El tag se vende

Seguimos trabajando en el trunk. Agregando nuevas funciones a mi proyecto y solucionando los problemas presentes en el branch. A medida que modifico el trunk, tengo que llevar estos cambios a mi branch. El código del branch lo está usando el equipo de QA. Cuando nos digan que encuentran que la solución sea estable, vamos a crear nuestro primer tag.

svn co https://svn.mydev.local/project-name/branches/1.0
cd 1.0
svn merge https://svn.mydev.local/project-name/trunk/

--- Merging r726 through r728 into '.':
svn ci -m "Merging changes from the trunk"