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.
Gerhard Fiedler wrote: > Trevor Leybourne wrote: >>From my personal perspective I have to disagree. I'm the manager and >>have been trying to get developers and doc specialists to use the >>concurrent model and they won't touch it. > > > I know what you're talking about. Developers not used to merging fear it > like hell :) I think they are not comfortable with having to take > responsibility of merging someone else's code into their own. It's not just that -- some don't want a system they aren't used to messing with their code because they aren't confident that it won't cause bad problems within (e.g. make it where VS won't open it anymore, mess up the delicate menu system with line position changes, etc.). Once people test out merging and understand it better though it's usually not a problem. I have had instance where I just change the way I do some things to provide easier merging across branches. For example, Visual Studio likes to rearrange large chunks of the control setup in VB.Net when you change something with the visual form designer. On a large form with lots of controls it can be a PITA. To compensate we coordinate the changing of visual elements when there is going to be merging across branches, or update before and immediately commit when doing UI changes on the same line. Another way is to build the bulk of your UI at runtime, or break it out into smaller custom controls that get updated less often. Regards, -- Glen Starrett