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.
> There *is* a difference. The fact that there was a merge > between branches creates a mergepoint value that has to be > stored. So the file > *contents* is the same but the RCS file is not... The problem is that despite of the only one file change (ok,ok, I mean the change from programmer point of view) EACH back an forth merge to HEAD and to BRANCH will create the new revision. I know that actual *.*,v file change is minimal and cause no issue from CVS point of view but the file looks different from user point of view (many different revisions) but all this revisions do have null diffs. And so an auditing tool that produces list of changed files between two code releases displays many "changed" files that in reality does not mean any code change at all. Anyway, it was just notice to support the branching case. I was already told some time ago "do not do that" (merge back and forth) so we got used to it and manually do not committing files with zero diffs (we use TortoiseCVS. btw, Tortoise guys, how about Tortoise improvements -> new command in Commit dialog - "uncheck files with zero diffs") Best Regards to all, JP _____________________________________________________________________ This email message, including any attachments, may contain confidential and proprietary information for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any use, copying or dissemination of this message is strictly prohibited. If you received this message in error, please notify Brooks Automation, Inc. immediately by reply email or by calling Brooks US Headquarters at +1 978-262-2400. Then delete this message from your system, without making any copy or distribution. Thank you.