[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN Usage - working on both tag and trunk

From: David Weintraub <qazwart_at_gmail.com>
Date: Thu, 11 Nov 2010 10:11:39 -0500

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

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
Received on 2010-11-11 16:12:15 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.