Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

resolving svn binary conflicts

Tags:

svn

conflict

I use svn for a project im working on with a couple of other developers. Svn works fine for source control however we are all ways getting conflicts when we commit the dlls.

When i do i resolve the conflict (which deletes my dlls as the diff program cant handle binary files) then have to rebuild to commit. How are you meant to resolve conflicts like this?

Edit:

The dlls are in a separate svn folder as the project is a game mod and non programmers need access to the latest builds.

like image 804
Lodle Avatar asked Jan 04 '09 09:01

Lodle


People also ask

How does svn solve tree conflict?

The only way to resolve a tree conflict via Subversion is to accept the current state of the working copy. Thus, if the local version of a file or folder is not the preferred one, the Revert command should be run on it.

How can I see svn conflicts?

Step 1: View Conflicts Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: Subversion is complaining that there is a conflict with the README file, and Subversion does not know how to solve this. So Jerry chooses the df option to review the conflict.

What is a tree conflict svn?

A tree conflict is a conflict at the folder level and occurs when the user runs an update action on a file but the file does not exist in the repository anymore because other user renamed the file, moved the file to other folder or deleted the file from repository.


2 Answers

If it's a DLL that you are BUILDING (rather than an external one you have no source for) then the source should be in source control, not the binary.

If you don't want to include it in that particular repository then you can include it as an svn:external.

like image 55
Steven Robbins Avatar answered Sep 25 '22 05:09

Steven Robbins


As mentioned in other answers here: you shouldn't version your generated dlls in the first place. But if you really have to version them, then you can resolve a conflict without using a diff tool which removes your dll files:

For every conflicted file, Subversion places three extra unversioned files in your working copy:

filename.mine

This is your file as it existed in your working copy before you updated your working copy—that is, without conflict markers. This file has only your latest changes in it. (If Subversion considers the file to be unmergeable, the .mine file isn't created, since it would be identical to the working file.)

filename.rOLDREV

This is the file that was the BASE revision before you updated your working copy. That is, the file that you checked out before you made your latest edits.

filename.rNEWREV

This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.

Here OLDREV is the revision number of the file in your .svn directory, and NEWREV is the revision number of the repository HEAD.

Now, to resolve such a conflict, remove the additional files you don't want:

  • if you want to keep your own dll, delete the files filename.rOLDREV, filename.rNEWREV
  • if you want to keep the dll from the repository, delete the files filename.rOLDREV and filename.mine, then copy filename.rNEWREV to filename

after that, execute

svn resolved filename

to tell Subversion that you resolved the conflict yourself.

like image 23
Stefan Avatar answered Sep 23 '22 05:09

Stefan