confusion between SVN and code backup by month/date/time whenever i make major or important update to the code

Question

I am working on two different project simultaneously where whenever the changes are made we use

1. Tortoise SVN for project A
2. Backed up by folder for Project B (this is done by me on my system)

I find SVN good for maintaining the latest code server machine and update it whenever necessary.
For Project A, I happen to make alot of changes to the project A and I am advice not to commit the changes again and again but just a major change all at once.
But since in not alone on project A I tend to make code backs by folder every time I make an important change so I can go back and return if some conflict occurs.

But what should I do in case of the project B?
where most I am on the project (as of now).
Should it be SVN or folder backups?

The reason I do folder backups for the project B is that
sometimes the build given to the client fails/buggy so instead of making them wait for it to fix
I just go and open the project and compile the last working build and give the executable so they can carry on their work and not wait for me to fix it (may take long).

I am working with Delphi on both the projects.

Answer 1

im advice not to commit the changes again and again but just a major change all at once

It's wrong advice.

project B where most im on the project (as of now) should it be SVN or folder backups

You should use version control in any project.

Backups and version control are not the same thing, although an external repository (centralized, or distributed in another computer) is a backup in itself, and backups (e.g. dated folders or zip files) together with some diff tool (e.g. WinMerge) could serve as a very rudimentary version control tool. But since excellent version control systems are available for free, there's absolutely no excuse not to use them.

Of course, backups must be taken in addition to using a version control system.

Answer 2

The reason I do folder backups for the project B is that sometimes the build given to the client fails/buggy so instead of making them wait for it to fix I just go and open the project and compile the last working build and give the executable

This is precisely the problem source control is meant to solve (using branches/tags). You would do yourself a favor in the long term by switching to SVN. You will realise how wise such a movement was (would have been) the first time you need to provide a hotfix to a bug in an older version while you are in the middle of developing a new feature in the latest version, which must not be deployed yet. With SVN, merging between different branches is way easier and safer than manual diff & merge between different backup directories.

Answer 3

You could switch to mercurial (distributed version control). This way you can commit as often as you want (on both projects).

In project A once you have reached a critical mass of commits that are acceptable you can all push them to the subversion repository (using HgSubversion*). If the number of commits is a Problem you can use either mercurial queues (Tutorial) or make a little home-made fix by rewriting all your commits into one. For example export them all as patches -- easily done with TortoiseHg -- and then import them into the repository again. Then commit and you have all your changes in one commit.

*To use HgSubversion you need the Python SVN bindings. In TortoiseHg (Windows mercurial client) these are included so you just download the HgSubversion source, include the path in the hgrc file and are ready to go.

Answer 4

• Use a source repository for all of your projects, as @JoonasPulakka and @PéterTörök wrote.
• Backup your entire source repository daily on another server/drive. Corruption/loss of source repositories may happen, and it is the only way to recover the the whole history of your changes, not only the last version. There is a question on SO on what is the best way to backup an SVN repository.
• Tag/Branch your minor/major changes. If one of these builds is released to the client, and fails, you should be able to fix that branch and release a fix, and report the change to the HEAD branch. Sometimes, though, there may be valid reasons to not fix a previous version (as you mentioned), and releasing the latest version that already fixed the problem may be the best solution. Anyway, this is your choice, and the only way to be able to fix a previous version is to have it in the repository, AND to tag it appropriately.

Edit: on the subject of SVN, as @PéterTörök wrote, merging branches is way easier than with some other source repositories, you already made a good choice there.