Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MergeInfoDisplay" page has been changed by JulianFoad: http://wiki.apache.org/subversion/MergeInfoDisplay New page: == Aim == Make it much harder to merge the “Wrong Way” by accident. Identify the typical merging tasks, which may vary depending on the requirements of the user’s team. Make the typical merging tasks easy to perform; look at TortoiseSVN and other existing GUIs for examples. Clearly distinguish tasks that have different meanings but may currently have similar or identical syntax, to reduce the risk of a user performing a merge that produces the desired output now but will adversely affect future merges. Make it harder to accidentally specify merges that are unusual and not well supported. Implement these measures by building onto Subversion’s existing library API, command-line UI, client-server interface and/or any other suitable level. If this requires knowledge of the user’s branching model and rules, provide a simple way to configure this and provide one or more typical configurations. A pre-requisite for designing and implementing such guidance is a clear statement of what merging scenarios Subversion supports. See the document [[https://docs.google.com/document/d/1wUCZOEywizf88BGjQn8RWqZ3reOoQXEsOnMOybK6qpI/edit?hl=en_GB|Supported Merge Scenarios]]. == Reporting -- What “svn merge” Should Say == “svn merge” should first of all give a summary of what it is about to do, using words that make sense to the user. Consider stopping to ask for confirmation (unless --no-interactive). Some of the output should be a summary of what is calculated as needing to be merged. That is not only a chance to check the user’s expectation, but in a merge that involves significant calculating of source revisions, it is also a chance for the user to see that Subversion has been doing something useful up to this point and is about to move on to the next stage of actually merging those revisions. So for example: {{{ $ svn co $URL/branches/dev1 wc1 $ cd wc1 $ svn merge --reintegrate ^/branches/feature2 Reintegrating '/branches/feature2' into working copy of '/branches/dev1' }}} and then a summary of the current merging status: {{{ Previous merges from ‘/branches/feature2’ into ‘/branches/dev1’ 4 source changes (latest: r144) in 2 merges (latest: r145) }}} and any warnings: {{{ warning: working copy contains modifications (all in ‘docs/’) }}} {{{ warning: working copy is not up to date }}} {{{ warning: ‘/branches/feature2’ is not up to date with ‘/branches/dev1’: 2 changes (latest: r166) have not yet been merged. Run ‘svn mergeinfo’ for details. }}} == Reporting -- What “svn mergeinfo” Should Say == In order for a user to understand what merges they have done and need to do, it would be most helpful if Subversion could tell them the current state of a branch with regard to merges. The existing “svn mergeinfo” command is near useless for such understanding: it just outputs a list of revnums without saying what that means in terms of whether the target is fully caught up or not; it doesn’t report anything meaningful about subtree merges and doesn’t even notice them by default; it doesn’t check that you specified a sensible source branch and simply says nothing if you accidentally specified the target branch. In a WC of ''feature branch'' “B”, which has had catch-ups through trunk@1234 except trunk@1215: * Mergeinfo summary: * $ svn mergeinfo ^/trunk * Origin: ^/branches/B@1200 (from ^/trunk@1190) * Merged from ^/trunk: * Origin-1214, 1216-1234 * Automatic identification of the ''parent'' branch: * $ svn mergeinfo * Parent branch is ^/trunk. * [... continue as for “svn mergeinfo ^/trunk” …] * Failed to identify a parent branch: * $ svn mergeinfo * svn: No parent branch configured for ^/branches/B * When no relationship is configured between this and the specified branch: * $ svn mergeinfo ^/branches/B2 * No declared relationship between ^/branches/B and ^/branches/B2. * Merged from ^/branches/B2: * 905,970-977 Mergeinfo should be “recursive” by default, reporting any sub-tree differences, where presently it does not. * How should the output look in the presence of subtree merges? * $ svn mergeinfo === Mergeinfo Diff (bug) === Diff, when displaying an added mergeinfo property on a sub-tree, should diff against the previously inherited mergeinfo, not say that all this new mergeinfo represents merges that have just been done. Similarly for a deleted prop. Discussed in [[http://svn.haxx.se/dev/archive-2011-09/0201.shtml|this email thread]].
