(This is a shared personal note, suggestions are welcome.)
Create a Subversion repository for a project, say The SVG Blog Icons:
- Create the repository on the hosting panel with a project name (e.g. Blog Icons) and project ID (e.g. blogicons).
- Import the files:
bash$ cd src/ bash$ ls blogicons bash$ export EDITOR=vi bash$ svn -m "First import" import blogicons http://svn.alkalay.net/blogicons/trunk
- Start over with a fresh copy:
bash$ mv blogicons blogicons.old bash$ svn co http://svn.alkalay.net/blogicons/trunk blogicons
- Create a repository for pointers to official releases and register the official release the files imported represent:
bash$ svn -m "Links of official releases" mkdir http://svn.alkalay.net/blogicons/tags bash$ svn -m "Official 20070518 version" cp http://svn.alkalay.net/blogicons/trunk http://svn.alkalay.net/blogicons/tags/20070518
- Check how it looks pointing the browser to http://svn.alkalay.net/blogicons/
Manage project files:
- Add files
bash$ cd blogicons bash$ svn add newfile.svg bash$ svn add newfiles.*
- Remove files
bash$ cd blogicons bash$ svn rm oldfile.svg bash$ svn rm oldfiles.*
- To embed the file’s meta information in itself as a comment
bash$ cd blogicons bash$ echo "<!-- $Id$ -->" >> file.xml bash$ echo "/* $Id$ */" >> file.c bash$ echo "// $Id$" >> file.cpp bash$ echo "# $Id$" >> file.sh bash$ echo "# $Id$" >> Makefile bash$ svn propset svn:keywords Id file.xml file.c file.cpp file.sh Makefile
Every time changes and commits happen, the $Id$ tag will be replaced as this examples:
<!-- $Id: file.xml 148 2007-07-28 21:30:43Z username $ --> /* $Id: file.c 148 2007-07-28 21:30:43Z username $ */ // $Id: file.cpp 148 2007-07-28 21:30:43Z username $ # $Id: file.sh 148 2007-07-28 21:30:43Z username $ # $Id: Makefile 148 2007-07-28 21:30:43Z username $
People use to put the $Id$ tag in the beginning of source files. The example show how to put in the end, but that’s because it is easy to represent it here in the documentation. You should put $Id$ tags in the beginning of the file.
- Commit changes to repository
bash$ cd blogicons bash$ svn -m "Changed color to red on icon A, moved the circle shape to left on icon C" commit
Use descriptive comments favoring WHAT changed on files and not which files changed.
bash$ svn -m “Improved icon A, deleted icon B, added icon C” commit
That’s really a bad idea. One of the worst problems with commits is useless log messages like that, no offense 🙂 I mean, Subversion already tells you what changed, what has beend removed from the repository and what exact lines you worked on, there’s no need to repeat that (shortly) in the commit message.
You’d rather explain why you changed those lines, how you fixed a weird bug or logic and do things like pasting a link with the bug number from your BT, that actually helps.
Also, if you use scripts such as svn2log to create automatic ChangeLog files for your project, you’ll ended up with a pretty much useless ChangeLog file.
And by the way: “Improve icon A”should be one changeset, “delete icon B”should be another changeset and so on…
Olá
(Desculpe, só vi agora o email)
No contexto de VCS (sistemas de controle de versão) :
Changeset é um conjunto de mudanças (em diversos arquivos), ao invés de simplesmente revisões de arquivo sem ligação umas em outras.
Ou, segundo a wikipedia: “Atomic commit is supported also by modern revision control systems and allows committing—uploading to the source—changes in multiple files (called a changeset) ” (em http://en.wikipedia.org/wiki/Atomic_commit)
Coisa que todo sistema de controle de versão moderno deveria suportar. No caso do post, o Subversion suporta.
Um exemplo: tenho uma função definida num arquivo.h e com sua implementacao num arquivo.c, e, por exemplo, um parâmetro da função mudou (o que pede uma mudança nos dois arquivos).
Em um VCS sem changesets, o .h vai para uma versão, o .c vai para outra e é necessário um recursos externo para ligar as modificações. E se coloca uma versão do arquivo sem estar casada com a outra, já era.
No Subversion, você muda os dois arquivos, e faz checkin de ambos ao mesmo tempo (svn ci arquivo.h arquivo.c); o changeset inclui as duas mudanças, e são inseparáveis do ponto de vista do VCS. Ou seja, ou a mudança é incluÃda ou não, sem perigo de inconsistência.
Os processos de desenvolvimento do kernel linux e de muito outros projetos, tanto abertos como proprietários são baseados em Changesets (principalmente na forma de unified diff).
E ganha um doce quem descobrir o nome do sistema de controle de versão moderno que não suporta changesets nem unified diffs.¬¬
Atenciosamente
Thiago Galesi