On Tue, Feb 24, 2009 at 11:17 AM, Robert P. J. Day
<rpjday_at_crashcourse.ca> wrote:
> the other reason [for committing to a branch] is that, if you're working with Q/A people, and
> they're trying to certify your software, any change to the code base
> -- no matter how trivial -- invalidates all their work and they have
> to start over. so you want to minimize all those picky little commits
> to the trunk.
Depends on why you're shipping a release off to QA. If you are working
on a possible release, then by all means branch. This is when you
should branch. We branch before each release when we have decided we
have a "release candidate". In that case, we give a build to QA and do
no changes except for the bugs QA finds. We fix those bugs, give the
release to QA, then wait for QA again. Meanwhile, we continue to code
on the trunk.
However, we also have QA do regular testing of our trunk builds. Every
few builds get shipped off to QA for more rigorous testing. In this
case, we don't branch, we simply continue to do development. Yes, the
current release isn't what QA is testing, but the issues QA finds are
still useful to us. The worst that will happen is that we fixed an
issue QA finds before QA gets a chance to report it.
Doing a branch just to keep what QA is working on doesn't buy you
anything. As soon as QA finishes, you'll have to move all the work QA
didn't test onto the trunk anyway.
In the develop-on-branch method, good developers know they're suppose
to merge their work into the trunk at least once per day -- maybe
more. And, that they need to keep updating their branches (by merging
from the trunk to their branch) to keep seeing the most recent changes
in the trunk. Otherwise, their changes might break the build.
So, a good developer is constantly doing merges back and forth between
the trunk and his branch. It really doesn't buy the developer anything
and wastes a lot of time with all the merging, resolving merges, etc.
I worked in a rapid development environment that used ClearCase UCM.
We had about a half dozen really top quality developers and I spent
most of my time working out merge issues because the developers would
deliver their changes to the main branch three or four times per day.
However, a bad developer will simply keep his work on the branch and
rarely will deliver code back to the trunk or merge the changes on the
trunk to his branch. That's just going to break his code, and he knows
his code is good cause it works on his computer. Instead, he'll
deliver his code right before we declare a release candidate, then
we're stuck untangling the tens of thousands of lines he sent us.
Okay, a bad developer will mess up a project no matter how you do the
branching, but I haven't seen a great advantage in developing on a
branch. It seems to add a lot of overhead without giving you much
benefit. Remember until Subversion 1.5, Subversion didn't have merge
tracking which made it a poor choice for using development branches.
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1221959
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 20:00:48 CET