[cvsnt] Re: Branch merging - this seems wrong...

[Prochazka, Jan]

> 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.