[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