Managing binary file merge conflicts - specifying repository or working copy.

19 views
Skip to first unread message

Brian Bennett

unread,
Nov 17, 2017, 10:17:45 AM11/17/17
to TortoiseSVN

Environment:

Desktop has TortoiseSVN 1.8. Server is running Subversion Edge 4.0.0.

 

Repository layout and initial contents:

file:///C:/TEMP/SVN/mergeinfo

trunk/

ApplicationA/

Program.cs

app.config

Module1.vb

Example1.xlsx (13847 bytes)

branches/Dev/ (empty)

branches/Model/ (copy of trunk/)

 

No properties on Program.cs, app.config or Module1.vb files. Example1.xlsx has the following property:

svn:mime-type application/octet-stream

 

Use case:

·         trunk/ copied to branches/Dev/CHG1

·         trunk/ copied to branches/Dev/CHG2

·         branches/Dev/CHG1 checked out, app.config modified, Program.cs modified and Example1.xlsx modified (new size: 9095 bytes), changes checked in.

·         branches/Dev/CHG1 merged into branches/Model without any conflicts and committed.

·         branches/Dev/CHG2 checked out, app.config modified, Module1.vb modified, Program.cs modified and Example1.xlsx modified (new size: 3499 bytes) and changes checked in.

o   Note: changes to app.config and Program.cs are in conflict with the changes made via branches/Dev/CHG1.

branches/Model checked out, merge of all revisions from file:///C:/TEMP/SVN/mergeinfo/branches/Dev/CHG2 into this working copy generates the following expected conflict:


Before any action taken, the working copy looks like:

In this situation, we desire that the repository version (file:///C:/TEMP/SVN/mergeinfo/branches/Dev/CHG2/ApplicationA/Example1.xlsx size 3499 bytes) be the version to merge into the working copy. So we click Prefer Repository

Results in merge dialog:

Working copy now looks like:

We resolve the other 2 conflicts and check the status of the working copy and it shows:


Our expectation is that the ‘Prefer repository’ selection would have updated the Example1.xlsx file to the version of size 3499 bytes, but that did not happen. It remains at size 9095 bytes which is the version from CHG1 previously merged into branches/Model.

 

If we recreate our test case, but do our merge in command line, we get the desired results:

Before taking any action, the working copy shows as:

In response to our conflict, we enter tf (theirs-full)


The working copy now shows as:

The size of Example1.xlsx is now 3499 which is the file size from branches/Dev/CHG2. After all other conflicts are resolved, a status of the working copy now shows:


Example1.xlsx is now showing a modification as we expected.

 

Can you please guide us on how TortoiseSVN can replicate the same behavior that we get with the command line for a binary file such as Example1.xlsx?




Stefan

unread,
Nov 17, 2017, 10:35:35 AM11/17/17
to TortoiseSVN
For conflicting binary files, I suggest you use "resolve later" and then after the merge resolve the conflict manually.
Because the other "resolve" options assume text files and don't properly work with binary files.
Reply all
Reply to author
Forward
0 new messages