On Wed, Nov 10, 2010 at 1:26 PM, Jonathan dos Santos
<jonathan_at_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
qazwart_at_gmail.com
Received on 2010-11-11 16:12:15 CET