Officially: You only have to branch when you have revision "X" needing to be
fixed, but you are already working with revision "Y".
For example, I've released 1.0 and now am working on 2.0. A user found an
issue with 1.0 and needs a fix. I could put the fix into 2.0, but the user
will have to wait six months for 2.0 to be released. In this case, I branch
at 1.0 and do the fix.
The standard development method is to branch when you are about to do a
release and have a code freeze. That way, the code freeze is on the branch
and not the mainline development. Most developers can continue working on
the next release without waiting for all the bugs to be fixed on the final
release candidate.
In this method, the release itself takes place on the branch, and not the
trunk. That branch will slowly die as more and more customers move from 1.0
to 2.0. Once there are no more users on 1.0, the branch can be deleted.
Where some shops cause problems is creating a special branch for each and
every revision before working on that revision. For example, I am doing work
on Revision 1.0, I create a Revision 1.0 branch. When Revision 2.0 comes, I
create a revision 2.0 branch off of the trunk and merge Revision 1.0 onto
it. When Revision 1.1 comes out, I create a Revision 1.1 branch off of
Revision 1.0 branch, and if I have a Revision 1.1.1 and 1.1.2 planned,
that's two more branches (off of Revision 1.1 branch, of course!).
That's simply branching for branching sake and an insistence on some sort of
PowerPoint branching order. You end up with innumerable branches and an
absolute impossibility of keeping track of them all. It's usually some
manager who gets this bright idea and then forces you to implement it.
So, don't branch unless you have to. Maybe the single exception is to branch
on each release just so all releases take place on branches. If you do
further patches on that release, the branch is already there. If not, you
simply ignore that branch.
Then again, if you have a really small shop and never do patching because
you simply up all fixes in the next release, don't bother branching at all.
Most open source projects take this approach.
On Mon, Jun 1, 2009 at 1:39 PM, Theodore H. Smith <delete_at_elfdata.com>wrote:
> Hi everyone,
>
> I have a situation here where one developer prefers avoiding branching
> code (from release version 1 of software to v2), when possible because
> he finds branches a time-waste, due to workflow overhead when trying
> to make the same change to both the released v1 and the unreleased v2.
>
> And another developer prefers branching code from v1 to v2 ahead of
> time, "just in case", that something will change, and because he
> prefers to "think about" the two versions as separate code bases.
>
> The situation for both developers (working on the same product), is
> that right now there are no branched files or files we can for sure
> foresee that it will need branching. In fact for all the work I can
> forsee that there will be no need to branch any files. The only
> problem we can forsee are having to disable features for v2 that
> shouldn't be accessed yet from v1.
>
> So... what's the best way to go ahead? Assuming we want fast
> development times.
>
> 1) Branch the code anyhow, and make the workflow slower for developer 1?
>
> 2) Revert to non-branched mode, because it's faster and we have no
> need for any file to be branched, and tell developer 2 that he is
> being "precious" with his way of seeing things?
>
> 3) Something else? Can we have both branched and non-branched working
> directorys? Or is that simply an impossible thing?
>
> The situation is that both developers are pretty firmly "dug in" to
> their way of working and convincing either to change their way of
> working may be harder than finding something that works for both.
>
> Ideas anyone? feel free to give your opinions even if it's not so much
> "here is a technical solution" but more "well here is a personal
> solution to get one (or both) to have a different attitude."
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357659
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
--
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357834
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-01 21:35:32 CEST