I’m a few weeks into moving all of our source code into an SVN repo, and really starting to see the magic. I now have a very simple question that will dictate much about my approach to SVNing.
I was on site for a client for 3 weeks, working on the trunk of ProjA. Just before I left, I created a branch of the trunk under “ProjA/tags/release-09.11.17” (datestamp version number) so I could have their exact build for emergency bug fixes.
Just now the client called me on a confirmed a simple math bug and I fixed it. I’m wondering how to approach updating our repo, and I see having several options:
1) Commit changes to the ProjA trunk, and delete “ProjA/tags/release-09.11.17”
2) Commit changes to both ProjA and “ProjA/tags/release-09.11.17”
3) Commit changes to ProjA, create a new tag for TODAY “ProjA/tags/release-09.11.19” and delete the old tag “ProjA/tags/release-09.11.17”.
Any of these have pros/cons as I see it. In the coming weeks ProjA will see a lot of development that said client won’t see until I’m back on site again.
Thoughts and reasons? Thanks!!
It’s a bad idea (at least from what I know of tagging/branching) to delete a tag. The tag is there for your reference at a later date — think of it like a bookmark in time. If you want to find the code you put into that release, the tag will always be there for you.
If you want to start a new branch of development based on that tag, you can always do that using
svn cp. You can commit your changes there, do some testing, and then tag that for release as a subsequent version, which is what it is — you can’t change what you’ve already released. Afterwards, you’ll probably want to port the fixes back to your trunk. Depending on what you have set up in terms of merge info (viasvnmerge.pyor core svn style metadata), and depending on how much work you actually need to do in the branch, this may be trivial or a pain in your neck.My takeaway advice is to try to avoid actually committing to a tag (other than its initial creation).