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.
On Fri, 4 Jun 2004 15:00:29 +0100, "Harrison, Andrew" <andy.harrison at anite.com> wrote: >> From: Tony Hoyle [mailto:tmh at nodomain.org] >> >> There are two parts to a mergepoint: >> >> 1. The automatic tagging, which is done by the client sending the tags >> from the last merge back to the server during commmit. That's what >> adds the 'mergepoint1' data to the RCS file. >> 2. The merging itself, which is part of the general merging algorithm >> - the mergpoint acts as a stopping point when looking for the range of >> revisions to merge with. >> >> Binary files get (1) but they don't get (2) as they're never merged. > >Ok. I know that the binary files don't get merged, but they do get copied. >Why can't the mergepoint that gets written in (1) be used? > >As I understand it, when merging branch1 -> branch2, the following rule >applies to binary files: > > if binary file has changed in branch 1 since branchpoint > copy binary file from branch 1 into (branch 2) sandbox > if binary file has changed in branch 2 since branchpoint > raise conflict > end if Nothing so complex... For a binary file a merge is always a conflict. In practice this means that if the version in the sandbox is different from the latest version then you will conflict. There is no branchpoint/mergepoint logic involved with a binary file as it's never needed. Tony