[cvsnt] Re: Mergepoints & Binary files

[Tony Hoyle]

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