On Wed, Nov 10, 2010 at 1:26 PM, Jonathan dos Santos <jonat...@prioriti.com.br> wrote: > generally we need to develop both in the trunk and the tag and sometimes > that’s really frustrating – mainly because some processes are huge and after > each minimal change we need to test it over and over in a dozen ways, I try > my best to use patches or to convince the deployer to make a new tag. Still > It happens more often the I wish it too, is there a way to prevent this > through SVN or its more of a company problem unrelated to svn usage? Or > maybe its just me ?
A tag is a snapshot in time. If you modify a tag, you're ruining your snapshot. There are many hooks that allow you to create a new tag, but won't let you make changes in a tag once it is created. The very first hook script I wrote did this once I realized that Subversion, out of the box, didn't have a mechanism to allow you to create, but not modify a tag. (I still have it if you're interested in it, but it's written in Perl which apparently is a no-no in this day and age. According to some people, I might as well have written it on punch cards in Cobol for a Borroughs E6000 mainframe) If you do have a tag you need to modify, create a branch off that tag, and then modify the branch. Once you've finished your modifications, you make a new tag. If your old tag was 1.3, you can create a tag 1.3.0.1. The best way is to create a branch when you're about to do a code freeze in order to work on a release. Then release and tag off the branch while developers work on the trunk for the release after that. If you need to fix bugs, you have the branch from your last release effort. Just modify the files on the branch, then tag again. Merging is a tricky issue. Some hold that you should modify from trunk and then merge into the branch, but this is somewhat unnatural. I have a release with a bug in it, I want to fix the release, and not futz with my mainline development. I'd rather make changes on the branch, do my release, then if necessary, merge the changes from the branch back into the trunk. You'll have to use the --reintegrate option in "svn merge", or do what many sites do, and don't bother with merging. If you have a defect tracking tool like Jira which allows you to assign a defect to multiple releases, you simply use that tool to show that a change took place on both branch and trunk. -- David Weintraub qazw...@gmail.com
