Thanks for the comments, Paul. Responses in line... Paul Burba wrote: > Julian Foad wrote: >> I want "svn mergeinfo" to show a high-level summary of the situation. > > Will we still be able to produce the old-style output via an option?
Yes, certainly; that code is currently absent from the branch for simplicity but yes; that was discussed previously <http://svn.haxx.se/dev/archive-2011-10/0048.shtml>. >> This currently shows the parts of the mergeinfo on the target that >> pertain to the source branch, including subtrees, in a summarized >> form. It could be summarized better; for instance, group together >> several target paths that all have the same source ranges merged to >> them. > > While we are in this space it's probably worth doing something about > mixed-rev working copies. Right now the 'svn mergeinfo' subcommand on > both trunk and your branch doesn't account for (heck, it doesn't even > *notice*) mixed-rev targets.[...] OK, thanks, I'll think about that. >> After that it currently goes on to print the "merged" and then the >> "eligible" revisions as lists of individual "operative" (non-empty) >> changes, with a (currently fake) classification of each change as a >> "merge" or an "original commit". That's more because I'm interested in >> the ability to do such classification, and not that I would >> necessarily want to show that in the "mergeinfo" command output. > > smi>svn info > Path: . > Working Copy Root Path: C:\SVN\src-trunk-2 > URL: https://svn.apache.org/repos/asf/subversion/branches/showing-merge-info > Repository Root: https://svn.apache.org/repos/asf > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 1189744 > Node Kind: directory > Schedule: normal > Last Changed Author: julianfoad > Last Changed Rev: 1189146 > Last Changed Date: 2011-10-26 07:56:31 -0400 (Wed, 26 Oct 2011) > > smi>svn mergeinfo > Assuming source branch is copied-from source of target branch. > Branch marker: 'ChangeLog*' (found on both source and target) > Source branch: ^/subversion/trunk (r1189762) > Target branch: ^/subversion/branches/showing-merge-info (working copy) > > ### It might be helpful to show the revision of the working copy target too. Yes; I initially didprint the directory's rev, but then, because that's misleading for mixed-rev, I pulled it out. Probably best to run the "svnversion" code to find out whether it's mixed-rev, and print accordingly. > Revision range that could be merged: > origin-1189762 > > ### So this line just shows "origin-Source_HEAD_Rev"? That's a bit misleading > ### since origin-1188748 *has* been merged already. Might be more useful > ### if 'origin' were replaced with the youngest revision from the source that > ### the target has been fully synced to (+1 of course since you are using the > ### 'M-N' range notation rather than 'M:N'): > ### > ### Revision range that could be merged: > ### 1188749-1189762 That info is going to come out in the "what's been merged" section. What I intend here is ... > ### Or maybe just spell out the actual value of the copied-from source + 1: > ### > ### Revision range that could be merged: > ### 1177607-1189762 ... yes, that. It's only missing at the moment because the API I'm calling doesn't provide it. > Revision range(s) recorded as merged: > DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 753: > /subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.c[1]: > 1067687-1072301 > DBG: mergeinfo.c: 738: filter_mergeinfo(in[55], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 753: > /subversion/trunk/subversion/libsvn_subr/svn_temp_serializer.c[1]: > 1067687-1072301 > DBG: mergeinfo.c: 738: filter_mergeinfo(in[59], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 753: /subversion/trunk[1]: 1177607-1188748 > DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 753: > /subversion/trunk/subversion/libsvn_fs_fs/temp_serializer.h[1]: > 1067687-1072301 > DBG: mergeinfo.c: 738: filter_mergeinfo(in[46], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 738: filter_mergeinfo(in[4], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 738: filter_mergeinfo(in[2], 836420-1189762 > subversion/trunk) > DBG: mergeinfo.c: 753: > /subversion/trunk/subversion/include/private/svn_temp_serializer.h[1]: > 1067687-1072301 > to target path '.': > 1177607-1188748 from same relative path > to target path 'subversion/include/private/svn_temp_serializer.h': > 1067687-1072301 from same relative path > to target path 'subversion/libsvn_fs_fs/temp_serializer.c': > 1067687-1072301 from same relative path > to target path 'subversion/libsvn_fs_fs/temp_serializer.h': > 1067687-1072301 from same relative path > to target path 'subversion/libsvn_subr/svn_temp_serializer.c': > 1067687-1072301 from same relative path > > Merged revisions: > r1067687 -- merge * > r1067696 -- merge * > r1067712 -- merge * > r1067714 -- change (at least on some paths) * > > ### I know this is work in progress, so maybe you are already aware of this > ### but all of these revisions predate the rev in which > ### ^/subversion/branches/showing-merge-info was branched from > ### ^/subversion/trunk, i.e. 1177607, so they are neither merged nor > ### eligible, rather they are part of the common history of the two. Yes; I *think* that's because of the strange mergeinfo on all the temp_serializer files, which I should be filtering it out because it's outside the relevant range, but I haven't implemented that part of the filter yet in "svn_client__get_source_target_mergeinfo()". (That's a poor function name as Stefan or Daniel already pointed out on IRC.) > ... > Eligible revisions: > r1177693 -- change (at least on some paths) * > r1177700 -- no-op * > r1177702 -- change (at least on some paths) * > r1177732 -- change (at least on some paths) * > > ### These revs are not correct either. This branch is synced with > trunk through > ### r1188748, so all of these revisions *have* been merged. Also, r1177700 > ### is flagged as a no-op, but like the other three changes was operative and > ### was merged to the branch in r1182334. Yup. The "no-op" and "change" flags are fake: the flagging code currently just says "no-op" when (REV % 10 == 0). That's why I didn't mention this stuff in the email. It would certainly be helpful if I made it print a warning about this, now that you and potentially others are looking at this branch and running it. Sorry to spring that on you! >> IDENTIFYING BRANCH ROOTS [...] > The section on subtrees in > http://wiki.apache.org/subversion/SupportedMergeScenarios is blank. I > assume you still plan to support merge-tracking aware subtree merges > right? The concept of a branch root is only to encourage best > practices and enable new features (i.e. the identification of source > branches below). Yes, correct. >> IDENTIFYING THE SOURCE BRANCH AUTOMATICALLY >> >> [[[ >> $ svn mergeinfo >> Assuming source branch is copied-from source of target branch. ### >> target is implicit '.' >> [...] >> Source branch: ^/subversion/trunk (r1189704) >> Target branch: ^/subversion/branches/showing-merge-info (working copy) >> [...] >> ]]] >> >> At the moment this only looks for the copied-from branch, which is not >> good enough; if we do this at all then we need a way to . Stefan also > > A way to what? Looks like you stopped mid-though here. I know the > feeling when it comes to merge :-) Oops. A way to be able to support less "obvious" branching patterns, e.g. copy trunk to br-1.0, copy trunk to br-1.1, then decide to use br-1.1 as if it's a sub-branch of br-1.0. And so on. People do that sort of thing. >> suggested it should only select a source automatically when it finds a >> branch root marker, as that means someone has deliberately enabled the >> feature. - Julian
