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.
> Your problem is that cvsnt marks the merge-from flag even when merging > differences between two revisions. You could have erased the > merge-from flag by doing (i.e.) an update with no parameters on the > file. > Unfortunately I don't know whether it's possible to erase a > mergepoint... I suspect that at the time of the last merge I would need to know which files have this potential problem, in order to delete their mergepoints. Is that correct? And I don't know a way to identify these files. > If there isn't, you could merge the branchpoint revision > to your branch, and then overwrite the resulting file with the branch > file =D I don't understand what you mean. Can you explain it a bit more? > Sure it's not an option, it's a _need_. How come you can even consider > committing changes without checking the code? Unless of course you mean > you're not going to merge at all. Of course I check all changes files before committing. The problem is that if a file has the described problem, some code is probably being removed incorrectly. And the changed files often have many revisions on both the trunk and the branch since the branch-point. I have to check all revisions after the branchpoint of these files, in order to determine if code is being removed incorrectly by cvs. Sometimes several different people have made the different revisions of the file after the branchpoint. I more or less have to consult them all with each file, if I want to make sure that no code is being removed incorrectly. Though this I possible to do on all app. 300 files, it is very time consuming, and it is normally less than 5 files which have the problem. That is why I would like a workaround. Regards, Anders