Question 1: Should I switch to working with command line instead of Tortoise? will it be safer?
No, tortoise SVN does everything you need to do pretty well and without the need for you to learn every command line command. I’ve used it plenty of time, and I never had problems that were related to it, the problems were related to me using it 😉
BTW: Tortoise SVN contains the same code under the hood as the command line client, so both are exactly the same kind of safe. But you can download SVN for the commandline as well and even use both in parallel. But that’s not really something helpful for you, I guess. Just take Tortoise SVN as it is much easier to use.
I think you missed to svn-add the subdirectories. As long as you do not add those, they won’t get committed. It’s just that they were not under version control so SVN did not know that those should be committed.
Question 2: Is there a way to postpone the version update notification until I confirm somehow that I have completed the upload of the new version successfully?
Normally there is no need to do so. Only for the very first version, the ZIP package is created automatically by the wordpress website. For any additional version, you need to tag a release before the new plugin.zip is generated.
So as long as you do not tag your next release, nobody will get notified about the new version.
Further Question 1: So basically I can upload the new version without incrementing the version in the main plugin file and the readme file and only when I see it the update was successful, I can update only those 2 files after incrementing the version.
That’s soemthing you can do as well. In the end you should update the readme.txt and the plugin file headers otherwise this won’t be user-friendly might create a wrong view.
I normally change those two files in my development trunk directly directly after I tagged the last release, so not at the end. This works very well for me. So this is quite the opposite then in your question.
Just tag for your next release and you are fine. The tagging will signal wordpress.org plugin repository that a new version is available. Until then, only the development version get’s upated after each commit if I remember that right. And that’s nothing problematic as it is the development version. Those normally do not get downloaded, and they are not announced with the update feature.
This should answer your other question as well: Update notifications aren’t send out unless you tag.
Further Question 2: Creating a branch is for major versions, right?
No, that’s unrelated. You can create a tagged version as a minor or bugfix release as well. The following principle is common:
MyPlugin version 1.0.0
This is the first major release.
MyPlugin version 1.1.0
This is a feature release within the first major release.
MyPlugin version 1.1.1
This is the first bugfix release for the first feature release in your first major release.
This is common. The wordpress.org plugin repository does not support this out of the box very well, it’s just counting up, regardless which position this is.
To fine-tune that, you can tag (within plugin headers) your plugin as being stable:
* Stable tag: 1.1
So on wordpress.org you can have one stable version only but next to that you can have countless of other versions as well. And you can (and should) tag them, too. Probably each time you fixed a bug or added a feature.
So you normally count up release numbers. If you’re creating a beta, you can add that behind, which is normally understood by users pretty well:
MyPlugin version 1.0.1-beta
This works as well. For a real life example you can take a look on the table at the bottom ob this plugin page on my homepage.
That’s a wordpress plugin that is also released on wordpress.org. The according line-up can be found here: http://wordpress.org/extend/plugins/better-http-redirects/download/