On Thu, Aug 28, 2014 at 2:27 PM, Stefan Sperling <stsp_at_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
Received on 2014-08-28 23:49:05 CEST