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.
On 2003-09-05, Glen Starrett <grstarrett at cox.net> wrote: [In reply to me saying] > > The new code extends this to allow a merge operation to be performed > > in the opposite direction after having done this. > That's odd--I haven't noticed a problem with that. Maybe I'm > misunderstanding what you're doing, or maybe I'm already tripping on > myself and didn't notice! The 3-way diff algorithm can sometimes detect that a patch has already been applied and everything will be hunky-dory. Sometimes, however, it can't and you end up with either merge conflicts, or bits that look like: <<<<<<< fred 1.3 // I did something here 1. // I did something here 2. ======= // I did something here 1. // I did something here 2. // Something else done. >>>>>>> 1.1.2.8 In fact, what should normally happen is that the "Something else done." line should automatically be merged without conflict. Sometimes you will also find a patch being reapplied. The problems you have will be highly dependent on the type of edits that are going on and how conflicting they are. [example elided] > I haven't noticed a problem (but I have seen null change updates as you > mentioned). Granted, not a lot happens on my MAIN outside my DEV branch > at the moment, but that will change once the other devs are delivering > to MAIN as well. You'll probably find that as more conflicting stuff is done, the problems will start to rear their head. You might not. (For the sake of interest I'll try and demonstrate how the old version doesn't always cope, and what the new version does differently in another post.) The null-delta issue doesn't break anything - but it will just get more and more "annoying" since practically every delivery to the mainline will end up updating every file (most of which will be null-deltas). I have a patch for that, but I'm worried it breaks other behaviour... (It seems to get rid of the fake "this file is modified" after doing a merge in which a null-delta is applied to the file. Which is good. But it might not be the only consequence.) > I'm using cvsnt 2.0.8... Did this technology get > slipped in early and I didn't realize? The one-way merge has been in for a while; the two-way merge is only in 2.0.9. diff3 being semi-smart (or semi-dumb, depending on how you look at it) has always been there :-) phil -- change "spam(s)" to "phil" for email