tags:

views:

5681

answers:

3

This has been bugging me for a long time -- how do I properly resolve a merge conflict within the SVN properties set on a directory? Say for instance there are two developers working on a project where svn:ignore is set on some directory. If both developers make changes to this property, when the second one updates, they will see a merge conflict.

Unlike file merge conflicts, a single file is generated in the directory called "dir_conflicts.prej", which the second developer must read and manually correct. Usually, what I end up doing is reverting all my changes to the local copy, then re-setting these properties manually with the info in dir_conflicts.prej. However, this is rather cumbersome when dealing with a big list of URLs in an svn:externals property, as many of our projects use.

There has got to be a better way to do this -- does anybody know how?

+1  A: 

I wish I could offer a more hopeful solution but from my experience its not currently possible to merge svn properties using TortoiseSVN. See http://svn.haxx.se/tsvn/archive-2008-09/0212.shtml.

Noah Goodrich
+1 for the definitive reference
Hobo
+1  A: 

Do you mean a merge conflict on commit/update or branch merge?

The SVN Book is pretty clear about the svn:ignore property in particular:

Subversion does not assume that every file or subdirectory in a working copy directory is intended for version control. Resources must be explicitly placed under Subversion's management using the svn add or svn import commands.

...

To force every user of that repository to add patterns for those resources to their run-time configuration areas would be not just a burden, but has the potential to clash with the configuration needs of other working copies that the user has checked out.

jtimberman
+4  A: 

Just a quick update after some additional research -- it is not possible to easily merge SVN properties. My originally described method (revert, merge data from .prej files, propset, re-commit) appears to be the best way to deal with this type of problem.

Nik Reiman