[fdo-internals] RE: Random question

Jason Birch Jason.Birch at nanaimo.ca
Fri Mar 6 13:07:40 EST 2009


I really would prefer not to see non-release-related branches under
branches.

I agree with all of your reasoning, and think that this makes the case
for placing multiple branches under /sandbox/

Jason

-----Original Message-----
From: Chris Erickson
Sent: March-06-09 9:54 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

I would just think a place to create branches would be useful.

Here's what we have internally:

trunk
tags
	Build x
	Build x + 1
	...
branches
	3.0
	3.1
	...
	TestNewFunctionalityX
	LongTermEnhancementY
	FixForDefectXXXThatCantBeMergedUntilAfterRelease

This gives the flexibility so that:
1) If I need to work on a piece of functionality for a while, I can do
so without disturbing trunk
2) I can isolate myself from other's changes on a branch while I'm
working on something, the merge their changes once I'm ready to go back
to trunk
3) I can work on something, then switch back to trunk to do something
else, then back to my working branch
4) I could check in a fix for a defect that wouldn't fit into the 3.4
release, but it would be nice to get the fix in version control (so I
don't 	lose/break it) and it can sit there until it is ready to be
merged after the release...
5) If I have code or modifications that I've made, that are not part of
FDO, I could be on my own branch, and merge FDO changes to my branch to
keep my 	branch up-to-date with the newest FDO updates.
	
I thought in concept that that is what the sandbox was, but it is only a
single branch and therefore wouldn't provide this flexibility...


More information about the fdo-internals mailing list