What you want to do is create Branches. It is as it sounds a branch in your source tree, typically a copy of your source when you release it. You would commit into this branch for the critical updates, and build the update from this branch.

What you are commiting into right now would be the trunk and you would code version 4 in there. If any major changes are commited to version 3, and you would like to have it in version 4, you would do a merge from the branch (v3) to the trunk(v4) to bring the changes over to the trunk.

You can also look at tags, which are like branches but link to a single version, typically the last revision of a version (or the first).

It depends.

You can keep version 4 in the trunk and continue developing on V4. Version 3 would be a branch, that you’d update as needed. The benefit of this approach is if a critical issue was discovered in V3 that is also in V4, you could do a simple merge on the file(s) across the branches.

The other option is to create and entirely new repository for V4. This will give you a fresh start. The downside is the change history is reset and you will not be able to merge files via Subversion. You’ll have to use a program such as Beyond Compare to merge in changes.

Personally I would stick with the first approach. Create a V3 branch and maintain the code and the updates in this branch. The new V4 code can be developed in the trunk.

I found an excellent guide to this situation:

If you want to be able to both develop a newer version (in trunk) and 
fix bugs on an older version, what you want is a branch for the older 
version. You can fix your bug in the older version's branch, then 
make a new tag of that. 
Example: 
/repo/ 
        project/ 
                trunk/ 
                branches/   
                tags/ 
You've developed your software in trunk and are now ready to call it 
version 1.0. You make a branch and a tag: 
svn cp $REPO/project/trunk $REPO/project/branches/1.x 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
Now you continue to develop in trunk, adding new features, and this 
will eventually become version 2.0. But while you're doing this, you 
find a bug in 1.0 and need to fix it quick. So you check out branches/ 
1.x, make the change, test it, and commit it. Then you tag that as 1.1: 
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1 
/repo/ 
        project/ 
                trunk/ 
                branches/ 
                        1.x/    
                tags/ 
                        1.0/ 
                        1.1/ 
If the bug also exists in trunk, then you need to port your bugfix to 
trunk. "svn merge" can help you there. 
cd trunk-wc 
svn merge -c$R $REPO/project/branches/1.x . 
where $R is the revision in which you fixed the bug on the 1.x 
branch. Now you test the fix in trunk and then commit it. Now the bug 
is fixed in trunk too. 

What you are asking about is the branch (and merge) strategy to use. So take the post of karthik t and take that as a recipe.

For some background, read the following resources:

• SVN Red Book for the repository layout (single vs. multi project repositories)
• Branch Patterns in your context, you will use a release branch per major version
• Software Configuration Management Patterns the base theory that is used in Subversion (and all other CM systems). See there the patterns, especially the release line there.