On Thu, Aug 28, 2014 at 2:27 PM, Stefan Sperling <s...@elego.de> wrote:
> On Thu, Aug 28, 2014 at 02:03:59PM -0700, Dan Ellis wrote: > > Hi, > > 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). > > That's good to know. > 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! > I'll have to experiment to see if I can create a rejected file and how it responds to see if it is easy to pick up on. > 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? > > 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 > My only concern about this approach (and I considered it) is about losing local modifications. This whole process would be fairly trivial if I didn't have to worry about that. We need to do things at times in the vendor-like area to stub out sections of code or put in some unique data handlers and update some of the properties. If I do a revert, I lose that information. An ignore properties merge that would show conflicts would really scratch this itch. I'm guessing I'll be stuck with the trip through diff and patch. Thanks, Dan
