On Thu, Aug 28, 2014 at 02:03:59PM -0700, Dan Ellis wrote:
> Hi,
>
> This has been brought up before but in a different context (
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3C20131107155018.GG10408@ted.stsp.name%3E
> )
>
> 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
> doing: http://svnbook.red-bean.com/en/1.7/svn.ref.properties.html).
>
> 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
> U integer.c
>
> 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
> to do.
>
> Can anyone talk about the robustness of a diff/patch solution to merging on
> text contents?
It would work fine, except for tree changes (though 'svn merge' itself isn't
exactly dealing with those in glorious ways either).
Note that 'svn patch' supports properties except svn:mergeinfo.
You'd have to create the diff using the --ignore-properties option.
And there won't be 3-way merge conflicts but reject files. Which
currently don't get conflict markers so be extra careful about
what you're committing!
> 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?
>
> Thanks,
> Dan
I don't think this is a merge problem as much as a conflict resolution
problem. Perhaps efforts would be a better invested in trying to improve
the property conflict resolution mechanisms of 'svn resolve' to make
your workflow easier?
It sounds like if you'd be in less trouble if you could 'revert' individual
property changes to the working copy's BASE state independently of the textual
changes, perhaps as a batch operation. There's no technical reason why the
conflict resolver couldn't be taught to make this easy but it's not implemented.
(code comment from subversion/libsvn_wc/conflicts.c)
/* ### the underlying code does NOT support resolving individual
### properties. bail out if the caller tries it. */
Received on 2014-08-28 23:27:43 CEST