Branko Čibej wrote: > Perhaps we had a bit of a misunderstanding here ... My point was, the > checks you mention have to always happen, not just optionally happen if > one uses the (by now quite misnamed) --reintegrate option. I'm not > arguing against sanity checks, quite the opposite, I'm arguing against > skipping them by default.
Oh, OK, at least we're clear now! So, my views... A 'mixed-rev' check is already done by default. There are two additional checks to consider at the moment, that are currently done for 'reintegrate' merges only. We might also consider adding further checks, such as whether the merge source or target has subtree mergeinfo that's inconsistent with its root mergeinfo, but let's leave such proposals for another thread and discuss here the two existing additional checks. The check for local mods in the WC: I think we should enable this by default. In the past I've felt that the user should be able to merge sub-ranges of the desired source in successive stages into a target WC, resolving any conflicts at each stage, and then commit the result. That requires merging into a target WC with local mods, for all but the first stage. That is also how Subversion's merge works internally: it breaks the merge source range down into successive sub-ranges if it needs to. However, in typical daily usage I suspect that accidentally merging with local mods is far more common than wanting to do a merge in multiple stages, and so I think enabling this check by default would be a good trade-off for needing an extra command-line option to do multi-stage merges. For exactly which merge commands should we enable this check? For all merges where a starting revision is not specified and merge tracking is used. I think these kinds of 'automatic' merges are the ones most commonly performed by non-expert users, and where this kind of simple safeguard is most effective and most needed. I would suggest we should not enable it for other merges, to maximize backward compatibility. In particular I note that cherry-pick merges are often performed in batches (merge -c140 ^/trunk; merge -c155 ^/trunk; commit). In principle that is exactly the same as performing a 'sync' merge in stages, but in practice more common, and because cherry-picking is also seen as more 'advanced' merging I think the safety advantage of a no-local-mods check would be outweighed by the inconvenience. The check for switched subtrees: I think we should enable this by default. I suppose the issue here must be that we don't have a compelling use case for supporting such a merge, and so we haven't defined and don't want to spend the effort of trying to define what such a merge should mean. We can explain what the merge code *does* in such a case, we just can't give a requirements-based reason for *why* it does what it does. Paul or anyone, please enlighten me if that's not the case. If that is the case, then surely it must make sense to enable that check by default. For exactly which merges? For similar reasons, and to keep the rules simple, I would sugegst this should apply to the same merges as for the no-local-mods check. The above discussion focused on the user's needs. There's a second aspect, which is whether the checks are necessary to protect our implementation from cases it can't handle. That's irrelevant to the local-mods check, as the implementation *must* be able to merge into a WC with local mods because it internally breaks a given merge source range into successive sub-range merges. I don't know it if handles switched subtrees 'properly'. This discussion doesn't seem to be specific to the 'symmetric' mode as far as I can see. The default checks of a '--symmetric' merge should be the same as those of a 'sync' merge, which should be a subset of or the same as those of a '--reintegrate' merge. Thoughts? - Julian
