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: > Why is that "blech"? It's been pointed out that a file may validly contain the conflict marker text, in which case grep would flag it incorrectly. Using grep is IMHO an ugly workaround to a problem that shouldn't exist in the first place -- but that's just my view. YMMV. > Maybe it's because I'm used to it, but I don't think that > cvs(nt) has much of a chance of knowing when I resolved a > conflict. I meant that CVS(NT) "knows" in the sense that it will permit a commit instead of blocking it. If I edit a file after a conflict, CVSNT (internally) changes its state from "not committable" to "committable". However, it is shown as having "conflict" status in both cases. (OTOH, CVS will change the status from "conflict" to "modified" to show that the file is now allowed to be committed.) > It seems to me that the way you say cvs works wouldn't help you with > leaving a resolution half-finished. The moment you save the file, the > conflict marker is gone (you said) I assure you, CVS behaves the way I said it does :-) > and you need to use some other method to keep track of those files. I was considering what (for me) is the most common case, where the conflicts are easily edited out, so I don't generally have half-resolved files lying around. On the occasions where the merges are (apparently) successful but in fact have not been correctly resolved by CVS(NT), then it's a much trickier scenario which can take a while to debug. But that's when pre- and post-merge tagging is useful, which is good practice on any complicated merge anyway. > Being able to run an update command that resets the conflict > status seems to be a useful thing, though. I'd be happy with just that one addition. In the meantime I'll live with the "blech" workarounds :-) -- Tony