On Thu, Aug 28, 2014 at 2:27 PM, Stefan Sperling <stsp@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
|