Subversion was good for its time, but a new generation of version control systems has sprung up — DVCSes (“distributed” version control). The new model is superior even for individual developers; some examples:
To get started all you have to do is enter a command to “turn this directory into a repository (a versioned directory)”, rather than having to choose/set up a server, access control, layout, naming schemes, etc as the “centralized” model (CVS, SVN, etc.) requires.
In a typical centralized VCS, when you commit changes, they are permanently in the repository as a new version; if it turns out you made a mistake, not in your code, but in how you added it to the repository (e.g. forgot to include a file), you have to make a new revision. With DVCSes, you can prepare your changes as a series of individual commits/revisions and polish and revise them before making them part of the permanent/public record. The major benefit of this for development is that it means you can commit often — every time you have made an improvement, commit it, thus preventing yourself from accidentally overwriting it without record during further development. If you make a mistake, or if the changes you made turn out to be a bad idea, you can always revert to last commit without losing anything else; and the diffs between revisions become single-topic, so more straightforward to understand.
I personally favor Git as being quick to use and flexible, but Git is generally considered obtuse in its command syntax so I wouldn’t specifically recommend it to someone new to version control. There are also Mercurial (hg), Bazaar (bzr) and Darcs (that last being a bit of an oddity in itself).
I recommend against using Subversion for new work.
Subversion was good for its time, but a new generation of version control systems has sprung up — DVCSes (“distributed” version control). The new model is superior even for individual developers; some examples:
To get started all you have to do is enter a command to “turn this directory into a repository (a versioned directory)”, rather than having to choose/set up a server, access control, layout, naming schemes, etc as the “centralized” model (CVS, SVN, etc.) requires.
In a typical centralized VCS, when you commit changes, they are permanently in the repository as a new version; if it turns out you made a mistake, not in your code, but in how you added it to the repository (e.g. forgot to include a file), you have to make a new revision. With DVCSes, you can prepare your changes as a series of individual commits/revisions and polish and revise them before making them part of the permanent/public record. The major benefit of this for development is that it means you can commit often — every time you have made an improvement, commit it, thus preventing yourself from accidentally overwriting it without record during further development. If you make a mistake, or if the changes you made turn out to be a bad idea, you can always revert to last commit without losing anything else; and the diffs between revisions become single-topic, so more straightforward to understand.
I personally favor Git as being quick to use and flexible, but Git is generally considered obtuse in its command syntax so I wouldn’t specifically recommend it to someone new to version control. There are also Mercurial (hg), Bazaar (bzr) and Darcs (that last being a bit of an oddity in itself).
I recommend against using Subversion for new work.