On 22.03.2012 17:16, Mark Phippard wrote: > On Thu, Mar 22, 2012 at 12:12 PM, Julian Foad > <julianf...@btopenworld.com> wrote: >> I suggest we should leave the --reintegrate option available, meaning "do >> stricter checks", and after doing the checks >> it will run the symmetric merge code. Currently the checks are "no local >> mods" and "no switched subtrees" >> and "no cherry picks"[1], in addition to the "no mixed revs unless >> overridden" that applies to all merges. > Let me just see if I understand what you are saying here (only talking > about what is now a "reintegrate" scenario): > > 1) User could just run svn merge. Merge will do the right thing, but > the existing reintegrate checks would not happen. > > 2) User could also use svn merge --reintegrate. Merge would still do > the right thing, but the additional checks would happen.
I'm confused. What additional checks would --reintegrate do that your common or garden merge would skip? What kind of check do you think you can safely skip without throwing all the effort you're putting into fixing the merge algorithm out the window? I've been assuming all along that --reintegrate would simply become a backwards-compat no-op. -- Brane
