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.
Arthur Barrett wrote: > See the manual for the reasons and the defined behaviour: > http://www.cvsnt.org/manual/html/Conflicts-example.html Yes, I read that. It's confusing because it seems to imply that by changing the timestamp of the file, the conflict will be *visibly* resolved. It isn't. The status doesn't change, and the only way I can find out if a conflict has been resolved is either to grep for the conflict markers (blech) or try a "cvs -n commit" and see what happens (blech again). IMHO again, since CVSNT knows that the conflict is resolved, it should tell me somehow (like changing the status, as CVS does). > Read up about change sets (bug id's) [ ... ] Bugids do get round the issue of not having all commits in one commitid, but that's not my real issue here, which is that of invisible conflict resolution. > I'm pretty sure "cvs update" does that. If I have conflicts > I always cvs update again before I commit (usually because on > seeing conflicts I decide to leave the problem until I'm in > the mood to resolve the conflicts). No, it doesn't. I tried that already (and just tested it again now) and "cvs update" has no effect on the conflict status. Like you, I sometimes leave conflicts for later resolution; and sometimes I have to leave the resolution half-finished and resume it later. It's *really* annoying that I can't come back and easily see which files I've sorted out and which I haven't. -- Tony