Managing SVN tags and trunk

Question

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!!

Answer 1

If you don't want any of the changes in the trunk to get released I would change the ProjA/tags/release-09.11.17 then merge those changes into the trunk

Answer 2

I believe SVN gospel is that /tags is for doing just what you did-- marking a specific moment in time where the code was in a known state. I think what you want to do is create a branch in /branches/client which you can then keep up-to-date with merges from the trunk. You can ALSO copy a datestamped version over to /tags when you're done just as an aid to memory.

Answer 3

I recommend that you commit your changes into the release branch and re-deploy the code from the release branch. Then, you can merge the branch changes back into the trunk for future releases.

Using that method, you will preserve the integrity of the release code but also make sure the fix gets into future releases.

Answer 4

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 (via svnmerge.py or 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).

Answer 5

I think that you are looking at it backwards, if there are ongoing, overlapping, packaged changes the preferred way to go would be to make those edits in a branch. Bug fixes, and short-term patches would go into the trunk.

While working on the longer-term project, the bug fixes can be merged into the branch, to ease that branches' final merge back into the trunk.

So, your emergency fix would go into the trunk, and be merged into branch/release 09.11.17.

Answer 6

If you don't want all the changes between ProjA/tags/release-09.11.17 and ProjA/trunk@HEAD to be in release ProjA/tags/release-09.11.XX (with XX being the date of that bugfix release), you can do is this:

1. copy ProjA/tags/release-09.11.17 to ProjA/branches/fix_math_bug
2. fix the bug on that branch, run the tests (here you could also merge other bugfixes from the trunk if you want to)
3. copy ProjA/branches/fix_math_bug to ProjA/tags/release-09.11.XX
4. delete ProjA/branches/fix_math_bug