On Tue, Nov 16, 2010 at 4:52 AM, Neson Maxmelbin (RBEI/EMT5)
<maxmelbin.ne...@in.bosch.com> wrote:
> I want to setup a reliable development process for SVN in our environment.
>
>
> The initial baseline of the project will be in trunk folder.
>
> For the first Release, the trunk is checked out , changes made and then
> commited into trunk.
>
> It should then be tagged into the tags folder as Release_xyx .
> The tag Release_xyz is then considered as baseline for the next Release.
>
> For the next Release
>
> * Developers should checkout from the tag Release_xyz .
> * Make the necessary code changes.
> * Switch to trunk
> * Commit changes to trunk
> * After all changes are done, Integrator tags the HEAD revision to a new tag
> Release_xyz2
>
I would not let developers checkout files directly from the tags
folder and modify. That's asking for trouble. Someone is going to
accidentally check in a change to a tag. Why not simply continue off
of Trunk?
I know many sites believe the Trunk should be preserved as some sort
of shrine to production release, but that's what tags are for!
Instead, keep it simple: Mainline development is on the Trunk. Once
you create a tag, just keep hammering away at the Trunk. When you do
your next release, just tag Trunk one more time.
Ah! But, what if there's a patch needed?
Simple, copy the tag to a branch, and make your changes there. Then
when you finish, tag from the branch. For example, you just released
Release_1.0, and are working on Release_1.1. A bug is discovered in
Release_1.0, and you need to patch it, create a branch:
$ svn cp svn://svn/project/tags/Release_1.0 svn://svn/project/branches/1.0
Now, you make your patch. Just copy it back to tags:
$svn cp svn://svn/project/branches/1.0 svn://svn/project/tags/Release_1.0.1
After a few decades of experience, I've found the best method to do a
release is to branch on "code freeze" or "feature complete" and
release off the branch.
For example, I'm working on Release_1.0, and we reach a point where
all the code is pretty well completed for Release_1.0, and we're ready
for testing, fixing bugs, and waiting for QA to approve a Golden
Master. At this point, some of the developers are going to get
frustrated because they're not doing all that much. This is the time
to create a release branch:
$ svn cp svn://svn/project/trunk svn://svn/project/branches/1.0
Developers who aren't working on the release continue to work off of
the Trunk for the next release after Release_1.0. Meanwhile, the
developers who are prepping Release_1.0 will work off the branch I
just created.
We get to the point where we are approved for the release. We make our
tag off the branch:
$ svn cp svn://svn/project/branches/1.0 svn://svn/project/tags/Release_1.0
And, now we merge the bug fixes and other changes that were made for
the release off the branch and back to trunk (if they're still
needed).
We now have a branch that should be at the same as the tag, and no
more work will be done on it (for now). The next release, we'll repeat
the same procedure: Branch on feature complete/code freeze, finalize
the release on the branch, and tag from the branch. Rinse and Repeat.
Now, let's say you're working on Release 1.1, and a bug is found in
Release 1.0. You decide to patch Release 1.0 and make it Release
1.0.1. The procedure is quite simple: You have a branch that's already
at Release 1.0. Make your changes there, and retag to Release 1.0.1.
What about all those old branches? You can delete them when they
become obsolete. When do they become obsolete? When there are no more
customers on a particular release, and you won't have to do a patch.
--
David Weintraub
qazw...@gmail.com
