Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
"Phil Richards" <news at derived-software.ltd.uk> wrote in message news:mailman.177.1068193171.731.cvsnt at cvsnt.org... > On 2003-11-06, John Peacock <jpeacock at rowman.com> wrote: >> Glen Starrett wrote: >> > When I'm about to merge in a branch back to MAIN, I first merge MAIN >> > onto >> > the branch so that testing and conflict resolution happen on the >> > branch, not >> > on MAIN. Then when I merge the branch to MAIN it is seamless, >> > shortening >> > the time my sandbox is being updated on MAIN. >> Merging is _always_ performed against the local sandbox. You >> shouldn't need to do this double hop unless you are trying to >> do the merge on a sandbox that is being used for something else >> (like a web site). [...] > > Glen's approach (which happens to be the same as the one we use) > is extremely useful for certain types of development. > > [Slightly off topic paragraph coming up...] > > The problem with the "do everything on the branch and only worry > about mainline merging at the end" is that the merge can be > non-trivial. Especially if the branch has lived a bit too long. > We do *all* development on branches, and do test-driven development. > This means that we have a set of unit tests, and the mainline is > "guaranteed" to be in a state that passes them all. To minimise > the amount of effort to merge branches to the mainline, we "lock" > the mainline when we do it - for *this* to work, it makes sense > to merge the mainline to the branch as the last stage of the process, > get everything working, and *then* do the merge to mainline. > (That way, if the merge is harder than expected, we can "unlock" > the mainline, sort the problems, and start the process again - and > mergepoints *really* make this easy to do. We find that we > do lots of mainline-to-branch merges now-a-dats because it *is* > so easy.) > I'm curious how this works for you, the developing *only* in the branch? I assume good since I guess you wouldn't be doing it if it didn't work out ok. I was considering the same model as often we have developers working on features for different version simultaneously. Also, sometimes the developers are checking code into the wrong branches. If they new they always had to work only in the branch for the release they were working on then maybe there would be less issues. We're also currently using vss (and I'm about to move us to CVS) and most of the files are linked across projects. So we also get people checking into the correct project, but forgetting to break the link before they check in a change. Thanks, Nick