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?

Thursday, 17 January 2008

My photo-CV /yeap, I am looking for a new job/

I used to work hard, in a stress and time-critical environment - it is always a challenge for me.

I like to work with others - to cooperate to solve complex problems! IT world is too complicated to go thorough really alone. RTFMs, lists, IRC, friends...

It is very practical to document my work...

... but it is even better to share my knowledge with other people! /last yapc::eu 2007, vienna/

It is not so easy to optimize code and databases, to make it better, faster, more efficient and reliable - better for users... but it just need to be done /all those apache/mod_rewrite/squid/non-forking-light-servers approaches.../

having my workplace and codebase really nice is also a pleasure to dig more /cvs, subversion, good directory layout, getting best of all /etc/*, .ssh/.rc files/

simplicity of architecture & design, good ERM models and libraries can give project a real power! /from 2NF, 3NF to fast ETL tools and database tuning/

As a good developer, I always try to learn something new and get more from my work /enjoy safaribooksonline, free sources, books to do what need to be done the best way/