Thursday, 31 January 2008

Reasons to switch from CVS to SVN

Plenty of reasons to switch to SVN/subversion as soon as possible.

SVN is better - easier to usage, no hacks for typical development tasks like
changing file names, directory structure etc.

What developer can do in SVN compared to CVS:

- can change file names and their place in project directory structure preserving
history. ### It is very important if you can make lib named "foo", code it and
week later rename to more apropiate name. This is more agile.

- can store more than plain files: symlinks, file rights. ### There are
still some problems if you would like to store your server files with
exactly the same permissions, but it is much more better than in CVS.

- handling with tags and branches is more intuitive. SVN shows them as
separated directories. ### SVN propose structure for your project where
the default (HEAD) branch for development is named "trunk". Other branches
you have in subdirectory "branches" and tagged versions are under "tags".

- commits in SVN goes together as a "transaction". All files in commit must
pass to be added to SVN repository. ### This is more safer approach than
"every file goes own way" like we have in CVS.

- commits in SVN get unique revision numbers. Single commited files belongs to
such revision number. Single files don't have own version numbers. ###
This is just different than in CVS. It has one advantage: revision number
in SVN means "this exact snapshot of code", the same like tag in CVS.
Compared to CVS, you can obtain snapshot by date (same in CVS - but you
know, this is UTC or localtime, and which timezone, huh?) and also by revision
number, without tagging code.

- mayby this is admin problem but it is simpler to make SVN working through SSL
without unix accounts on remote server (SVN repo). Do you know how to do
it in CVS?

No comments: