I use the SVN layout suggested in the red book for my project, e.g. I did create the ^project/trunk, ^project/branches and ^project/tags subdirectories.
For the first release 1.0.0 of the project I copied the trunk revision 240 to branches naming it ^project/branches/release-1.0.0. Meanwhile the work on trunk continued to latest revision 271 and some bug-fixes from selected revisions (let's say some from r252 and some from r268, but not all changes committed in these two revisions to trunk) should be back-ported to the release 1.0.0 branch resulting in release 1.0.1. So I checked out release 1.0.0 into a new working directory and applied the bug fixes there manually.
Now my question is: if I commit the changes from this working directory of the ^project/branches/release-1.0.0 I will get revision 272 if I understand it correctly, but what about the next trunk revision when new changes in the trunk working directory will be committed? Will trunk be assigned revision 273 then?
And what would be the differences between trunk r271:r272 or r272:r273? Are they non-existing then much like the branches revisions r240:271 when looked at the trunk history with svn log -r271:272, respective svn log -r240-271 on branches/release-1.0.0?
Having used SCCS, RCS and CVS I find it somewhat confusing that there is no version/revision scheme uniquely identifying branches in SVN (such as version 1.0 revision 1 for example). Maybe I don't get the picture for what those revision numbers are in SVN, so what would be best numbering scheme for version/revision of the package itself and how do those numbers relate to the revision numbers of SVN?
Of course I would like to have contiguous revision numbers (in the sense of minor version numbers) such as 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1 and so on for the package itself, but in SVN's notation the 1.0.0 then is r240, 1.0.1 would become r272, but 1.1.0 is r268, while 1.1.1 would become r274 if I understand the red book correctly. Or do I mistake the term "revision" in SVN?
if I commit the changes from this working directory of the ^project/branches/release-1.0.0 I will get revision 272 if I understand it correctly
Yes, that is correct.
Will trunk be assigned revision 273 then?
Yes (although this is technically not 100% correct, please see my explanations below).
And what would be the differences between trunk r271:r272 or r272:r273?
Since r272 was a commit to a branch (and not trunk), there will be no difference for trunk between r271 and r272. However, since r273 was again a commit to trunk, the diff for r272:r273 will be non-empty.
A revision number in svn is an identifier for the state of the repository at a certain point in time. With each committed change, no matter where in the repository, the revision number is incremented by one so that each state can be identified uniquely. This implies that in some (most) revisions, only a subset of the files/folders in a repository may have changed. Or put differently: If you have a file at two different revisions, the only thing you know for sure is that the one with the higher revision is the one from a later state of the whole repository - whether the file has changed between the two revisions cannot be deduced from the revision number only.
As for your package number scheme: Most users of packaged releases do not care from which svn revision a certain package revision was created, thus the svn revision is usually omitted from the package revision name. I'd suggest to just continue to use your MAJOR.MINOR.PATCH numbering scheme. If in doubt, I recommend a search on SO for related questions.