>> Julian Foad 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.
Mark Phippard wrote: >> 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. Yes and yes. >> Or are you saying that 1 and 2 will be the same no matter what and the >> code will just figure it out? No. In either case, the code will figure out (in just the same way) what merge needs to happen. The high-level meaning of the "reintegrate" option would be merely something like "I believe I'm merging into a clean simple WC and I haven't been doing any cherry picking, so please alert me if you detect otherwise". >> As an API consumer via JavaHL, I would assume I will just have a >> single merge API I can run, as opposed to two today. And the API will >> do the right thing? Yes. Branko Čibej wrote: > 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? The checks of target WC state mentioned above. Of course, the name "reintegrate" would then be less than appropriate, and we could consider a new name that makes more sense for that "I expect this to be a clean simple merge" kind of meaning. Is the use of an asymmetric-sounding option name for a now-symmetric functionality what was making you uncomfortable? > I've been assuming all along that --reintegrate would simply become a > backwards-compat no-op. We could do that, but I believe the checks it does are useful in that kind of scenario. (I even have an idea how we might want to expand the checks further.) - Julian
