Svn Conflict

From Hash, Inc. WIKI

[edit] Send in any movie confilcts

If you get a conflict while working on the movie please check here for the latest instructions on how to handle this.

Please send the

• filename.extention.r1 (numbers will be different)
• filename.extention.r2 (numbers will be different)
• filename.extention.mine

to noel at hash dot com. He will help you resolve your conflicts.

When you update svn make sure you chech to see if you get any conflicts. Animation Master will try to notify you if you load a file that contains unresolved conflicts.

If you are sure you didn't mean to modify the conflicted file Then follow these steps to revert your changes.

1. Check to see if the conflict is on your working copy of the svn data.
   1. Find the conflicted file in your OS's file browser (Explorer on Windows)
   2. If you see files names conflictedfile.ext.mine .r1 .r2, then you modified this file and someone else modified this file.
   3. Deterime if you meant to change this file or not.
      1. If you are sure that you didn't mean to modify this file then, revert your changes.
      2. If you meant to change this file then send these files to noel at hash dot com
2. If the conflict isn't in your working copy send the full path of the file to noel at hash dot com.

[edit] Conflict info

paraphrase KenH Oct 28 2005, 03:32 PM post=141243
Edit: Can’t quite get my head round the svn data management system. What if two people grab a file off the server at the same time. Say tinman. One does the lip sync of the scene while the other does the actions. Then they commit their files to the repository. Does that not mean only the second person to update will only have his work preserved….Hmmm…..

Here is the official svn take on conflicts

An example.

Lets say tinman.mdl has:

<MESH>
cp1 pos = 10,20,30
blah blah
</MESH>
<GROUPS>
<GROUP>
name=group1
</GROUP>
</GROUPS>

not the actual mesh format but you’ll get the idea.

• Two people Tom and sally update to get that file
• Tom changes cp1’s pos
• Tom changes the group name to group2
• Sally changes the groups name to group2
• Tom ‘commits'’ which merges the new cp and group name into the repository
• Sally tries to ‘commit’ but it says that she must ‘update’ first because some one else already sent that file. She ‘updates’ and it merges thom’s cp change with no conflicts, and since they both did the same change to the group thats ok too. She can then ‘commit’ the merged file.

That is the common case, but what if both tom and Sally change the group name to two different things?

• Sally ‘commits’ and is told she must ‘update’ first and gets a conflict because both her and tom changed the name of the group.
• svn makes three temporary files
  • tinman.mdl.r1 (the revision before your changes)
  • tinman.mdl.r2 (the revision of the file that came down when you updated)
  • tinman.mdl.mine (your current revision)
• svn merges the file you got in the update into your file (tinman.mdl) marking any any conflicted areas with “<<<<<<<” like:

<GROUP>
<<<<<<< .mine
name=Sally's group1 name
=======
name=Tom's group1 name
>>>>>>> .r2
</GROUP>

• If Sally was using Tortoise the update dialog will beep, and list the conflicts in red.
• Sally uses a Diff/Merge tool or a simple text editor to search for <<<<< and finds that they both changed the name of the group.

In Tortoise you can right click on the conflicted files in the update dialog for options.

• Sally chooses her group name or Tom’s group name and marks tinman.mdl as ‘resolved’ (no longer conflicted). This removes the temporary files.
• Sally ‘commits’ so now anyone can ‘update’ the new revision of tinman.mdl

• OR Sally knows that she didn’t mean to make any changes, so she reverts tinman.mdl. This takes it to .r2 which is what Tom did. Caution revert will lose your changes

Conflicts are rare, two people have to change the exact same spot, but in different ways.

So until we build the conflict resolution into v13.0 it will take a little coordination between who works on what, or the conflicts will have to be resolved by using a svn graphical interface like the svn page mentions.

The cool thing with SVN is that if a conflict is resolved incorrectly or a mistake was ‘sent’ we can always go back to what it was and fix it. (You can loose your work since your last commit if you reslove a conflict incorrectly or just revert).

If you see an error message about a conflict when loading a file this means that someone had a conflict and marked it resolved with out really resolving it (leaving the “<<<<<<<” to “>>>>>>>” section in the file). v13.0 can’t load this correctly of course so it warns you.

[edit] See Also

Svn Walkthrough’s section on avoiding conflicts