I have create a tag named v1.5 off a branch. After some testing I found some bugs and it seems I have to propagate these changes to tag/v1.5. But I see some comments that do not suggest such practice of updating or merging a tag.
My question is what is best way to handle situations like this. Probably delete the tag and recreate it from the branch head revision ?
On
the best practice is not to delete tags in fact tags are not meant to be touched they are just labels, while its true that everything is a folder in any svn repository, the practice is to usually work on trunk, update branches in case of bugs, and leave tags as markers for previous work history for reference, branches can also be used for separate work, the best practice is to work with a single mainline single trunk pattern and to avoid branches as much as possible (continuous delivery integration) but in your case i would branch fro tag and update it and then merge back to trunk. tags are meant to stay. what i would do is copy the tag into a branch with branch name and do the update there. then I would merge it back to trunk. for automatic merges there is a cool utility for svn called automerger utility
Google and Facebook adopted trunk based development. development In the materials above, these Googlers talked about working on HEAD, and that checkins happen to HEAD at all times. Ashish says trunk a few times towards the end in a Q&A section, and he does mention an avoidance of branching for ongoing development (nothing to do with releases per se). So it’s official, Trunk Based Development (TBD) is what Google do, and boy do they scale it! (http://paulhammant.com/2013/05/06/googles-scaled-trunk-based-development/)
Tags, branches, etc. make no sense to Subversion itself, they are just folders and you can do anything you want. However, there are good practices, and tags mean something that you never change. You should have a workflow and stick to that.
For example, we make new developments in the trunk. When it's ready, we create a branch, like 1.5, and then create tags, like 1.5.1, 1.5.2, 1.5.3, etc. We add bug fixes and create new tags from it, we don't add new features to branches, and we never ever change tags. Then we merge the bugfixes from the branch to trunk when there are new developments. It is a very common workflow.
Here's a longer article, what I described above is called "stable release model" here, there is a good image to show you what happens where. There are also alternatives and a long discussion. I love those graphs, here's another one, but it's a bit confusing, arrows shouldn't cross tags, tags should always be a dead end.