Thanks. My sentiments exactly. Never branch really - and... I probably will
not branch for this either !!
And yes... so far of course I have never changed a tag of the version released
to the field and don't really plan to. I'll make another if necessary.
Just trying to think ahead in case.
--- On Wed, 11/3/10, David Weintraub <qazw...@gmail.com> wrote:
From: David Weintraub <qazw...@gmail.com>
Subject: Re: simple question on branching
To: "KM" <info...@yahoo.com>
Cc: "svn-apache-users-list" <users@subversion.apache.org>
Date: Wednesday, November 3, 2010, 10:36 AM
On Wed, Nov 3, 2010 at 9:44 AM, KM <info...@yahoo.com> wrote:
>
> We don't often use branching and/or merging based on the simple
> nature of our version releases with very little overlap.
>
> Any reason that creating a permanent branch on the tree would matter
> -- i mean never merging it anywhere? I don't see what harm it would
> have really - but I just wanted to be sure in case I decide to branch
> from the production version of the trunk instead.
Anyone will tell you that branching and merging is hell, and if you
can avoid it, you avoid it.
The standard is to keep branching to a minimum and only do it when necessary.
There are really two main reasons to branch:
Reason #1: You are about to do a release, and want to avoid developers
twiddling their thumbs as you do a code freeze. Branching allows some
developers to clean up the code on the branch and release from the
branch while other developers continue working on the trunk.
Reason #2: You are working on a new revision when a bug was found on
an older revision, and you want to fix that bug before the new
revision comes out. Of course, if you branched for Release #1, you
already have the branch you need for that bug fix.
Open source projects rarely branch. If you find a bug, they simply
tell you to wait for the next release (which probably comes every few
months). If you really must have the fix now, you grab either the
trunk source code where the fix might already be implemented or the
release source code and fix the problem yourself.
Nor, do open source projects care about keeping developers occupied
while they try to prep the code for a release. After all, they don't
pay the developers, so they don't care if the developers have nothing
to do.
If you don't need to branch, then don't branch. I've worked on many
projects which almost never branched and others that loved diagramming
complex branching schemes. (Release 1.0.1 branched from the Release
1.0.X branch which branched from the Release 1.0 branch which branched
from the Release 1.X branch.). I will tell you that ones that never
branched had better development and fewer problems.
So, if you don't need to branch, you're fine. And, if you do need to
fix a bug on a release, you can always branch from the tag and fix the
bug on that branch. (Or, you can find the revision that created the
tag and simply branch off the trunk from that revision.)
What ever you do, don't change your tags. Tags are suppose to be
snapshots of what took place and should be absolutely stable. When the
sun explodes into a fiery ball and destroys all life on Earth, any
alien being who lands on the Earth's charred remains and finds your
source repository should see the same set of files tagged as
REL-1.0.1 that you did the day you created that REL-1.0.1 tag.
--
David Weintraub
qazw...@gmail.com
