This has been brought up before but in a different context (
We maintain some vendor-like code on some branches that we periodically
want to merge into our development branch. The problem is that both in our
development branch and in the vendor-like branch, we use subversion
properties for some house keeping tasks (test status, etc.). When we want
to merge we cannot stop from pulling over these properties and end up
clobbering our house keeping properties and creating property merge
conflicts. I say vendor-like as the vendor-branch isn't just a simple
import/commit/tag, they develop in the same repository.
Being able to do a textual merge only and ignore the properties would be
great. Using custom properties doesn't seem to be an issue from reading
the SVN manual (and it actually encourages their use for just what we are
We really don't want to bring in details of the development done on the
vendor branch, just a comment within our branch saying we brought in xyz,
rev 1.1, so we ignore ancestry as well.
I see two possible solutions.
The first would be to include an --ignore-properties on the merge command:
svn merge -r <rev> --ignore-ancestry --ignore-properties <url> <wc>
The second would be to do a trip through svn diff to create a patch and
then apply the patch (from svnbook, basic merging):
$ cd my-calc-branch
$ svn diff -r 341:HEAD ^/calc/trunk > my-patch-file
$ svn patch my-patch-file
This second seems concerning in that it is an extra step and getting a
merge conflict when merging is nice. I'm not sure how robust the
diff/patch pairing is and what occurs when a patch can't quite discern what
Can anyone talk about the robustness of a diff/patch solution to merging on
text contents? Would exporting the vendor-like branch to an uncontrolled
area and doing a merge from there be an option? Does the
--ignore-properties switch on a merge break an SVN philosophy?
Received on 2014-08-28 23:04:28 CEST