There are two main ways to use branch, which I will call "branching by Rule" (twigs created by default) and "branching by Exception" (branches grown under exceptional conditions). I will touch on that later, but to simplify the answer I will take on the second strategy - where most of the development takes place in the trunk and only occasionally is made a branch. I believe that this strategy is more applicable to most existing projects, but it is only my opinion.
An example of workflow
Let’s say you and other developers started a software project. Each one writes a little code, does commit in the main repository, gets the other’s code using update, etc, until your system is ready to pass the testing phase (or QA, or whatever the next phase in your workflow is). The first thing to do is freeze your code in the current state - do not allow changes to it until it passes through all the testing stages until it is ready for production. If an error is detected at one of these stages, you should not change the code right there and move on; it is important that the changes made by the development team are frozen again and start the whole cycle again (otherwise the changes may introduce new bugs, which will not be detected unless the code returns to the testing team).
This is the time when the use of a tag is useful: if you are planning the version 1.0, and your code - if approved - will become the version 1.0, you can "tag" the current revision as 1.0 RC1 for example ("candidate 1 for release 1.0"). It is this review that the testing team will use, it is the one that the QA team will use, it is the one that the approval team/staging You’ll use it... and if they all approve, that’s the one that goes into production. If any of these teams veto the review, developers fix the bugs, tag the new review as 1.0 RC2 and send to the tests. Eventually one of them will be approved by everyone, and that same will receive also the label 1.0.
The developers, of course, can already develop the version 1.1 (or 2.0) if you want - you don’t necessarily have to wait for 1.0 be approved. But if the applicant for release (release) was rejected, it would not be a good idea to take the code the way it is - full of code that would only be ready in the next version - and try to finish it in a hurry to "fit" the version 1.0. It would be better to interrupt what is being done, take back the code with the label 1.0 RC1 and make the necessary changes therefrom.
This is the moment you make a branch - part of the review 1.0 RC1, create a new branch for the version 1.0 and you start to change it. You make how many commits are necessary in that branch, until it is believed that the code is stable enough to become the 1.0 RC2. When this is finally done, send it to the tests and work on trunk - maybe merging (merge) the corrections made in that branch the main code in trunk (not to have to repeat everything there). If applicable, of course. The branch created can be maintained - future changes in version 1.0 can from that branch (since all that is relative to the later versions will be in the trunk).
Finally, what if the version 1.0 is already in production and a new bug appears? It would not be good to simply say "wait until 1.1, in about 3 weeks it will be ready", the correct thing is to provide a 1.0.1 as soon as possible. This is done in the same way described above: the branch of 1.0 (in this case it is not necessary to create another, since 1.0 is ready, it will only receive bug fixes from now on), make the necessary changes to it and tag itself as 1.0.1 RC1. Make a 1.0.1 RC2 if necessary, in the same way as above, until one of them is approved and turns the 1.0.1. New bug? Goes to 1.0.2 RC1. And so on and so forth.
Branching by default
The flow described above assumes that all "main" development will be done in the trunk - which is often reasonable, because many projects are only deployed in one place (your company’s server, for example). But in others it is necessary to maintain several versions at the same time, for example when you have N clients with your system installed and each of them has a specific version - and no conditions to update every time a new version appears.
In that case, can be (but not necessarily is) better not to do the whole development in trunk, instead of creating a branch separate each time a new version is planned. Sometimes it is desirable to do this regardless of the scenario, since you can plan and develop several versions simultaneously, i.e. if you already know that you probably have a version 1.1 parallel à 2.0, it is difficult to know which is the most suitable to occupy the trunk, So how about you decide to "none of them" and give each version your separate branch? Even because in the first bug that appeared you would have to do it yourself...
If you choose this strategy, then the question remains: what to put on trunk? I would say that your role is to store the "last" revision of the code, the one that will "go forward" when new versions are planned and implemented. That is, if the 1.0 is in operation, you decided to add a 1.1 to immediately provide a cool functionality that you are implementing in the 2.0, but that you did in 1.1 is only provisional - not suitable for the next version, because you have refactored everything - so this code would not be merged with the trunk. A bug fix, which potentially affects all its active versions, has to be readily available to be merged with all "revision tips" (tips - I do not know if the SVN uses this terminology) relevant - thus justifying its inclusion in the trunk.
Other considerations
The use I described of tags is the minimum necessary for a healthy release management - you can create plus labels if you want, for example to name alpha and beta versions. In short, you use a tag whenever it is interesting to present a "frozen" version of the project to someone (not in the sense that this version will not be moved, but in the sense that whenever someone reports a bug in that version you know exactly in what state its code was when the problem was identified).
As for "changing an existing source code, or creating new sources in a project" this does not determine or is determined by the use of branches: if the change or inclusion occurs during the main development, it will trunk as everything else; if the change or inclusion occurs when maintaining an already "finished" version (i.e. in production, or in approval process), it goes pro branch of that version. Creating the branch, if it does not yet exist (if the project goes exceptionally well, with all the bugs of one version solved before starting to develop the next one, then it may never be necessary to create a single one branch).
This response was largely based on the articles Release Management Done Right ("Management of Releases Done Correctly") and Source Control Done Right ("Version Control Done Correctly"), contextualizing according to the request in the question (the originals are too comprehensive to be fully covered here) and with my personal experience (the versioning patterns, for example, are fictitious, and do not necessarily correspond to any "good practice of versioning").
I know two excellent articles (in English) on the subject: Source Control Done Right and Release Management Done Right (the first more directly on the subject, the second less, but still quite relevant). If there is interest, I can try to formulate a response based on them, but I would already say that it would be a "generic" response - since I do not dominate, or have not used, the SVN. If you still think it’s pertinent, tell me I’ll write.
– mgibsonbr
@mgibsonbr, for sure! I would be very grateful! = D
– James