On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.f...@wandisco.com> wrote: > At the moment, on the 'showing-merge-info' branch, I have several > things going on; here are some of them. > > SHOWING SUMMARIZED MERGEINFO > > [[[ > $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x > [...] > Revision range(s) recorded as merged: > to target path '.': > 875965,875968,...,1151036 (477 ranges) from same relative path > to target path 'CHANGES': > 875962-1130989 from same relative path > to target path 'get-deps.sh': > 878590,878607,...,1126007 (7 ranges) from same relative path > to target path 'subversion/include/private/svn_repos_private.h': > 878590,878607,...,1126007 (17 ranges) from same relative path > to target path 'subversion/libsvn_fs_fs/rep-cache.c': > 875965,875968,...,1126007 (456 ranges) from same relative path > to target path 'subversion/tests/cmdline/merge_tests.py': > 875965,875968,...,1126007 (432 ranges) from same relative path > 953878,1146121 from source path > 'subversion/tests/cmdline/merge_reintegrate_tests.py' > to target path 'subversion/tests/cmdline/svntest/main.py': > 991972 from source path > 'subversion/tests/cmdline/svntest/sandbox.py' > 875965,875968,...,1126007 (441 ranges) from same relative path > ]]]
Hi Julian, Questions and comments below. All examples done with ^/subversion/branches/showing-merge-info@1189744. > 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? > 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. At a minimum 'svn mergeinfo' should issue some sort of warning akin to what an actual merge generates, e.g.: smi>svn merge ^^/subversion/trunk svn: E195020: Cannot merge into mixed-revision working copy [1179544:1189744]; try updating first A few options we might pursue: 1) Refuse outright to operate on a mixed-rev target, raise an error, and recommend updating to a uniform revisions 2) Proceed, but warn that the target is mixed-rev and the results of an actual merge may not be what is expected (i.e. conflicts). 3) Other? > 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. 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 ### ### Or maybe just spell out the actual value of the copied-from source + 1: ### ### Revision range that could be merged: ### 1177607-1189762 ### 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. ... 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. ... smi> > IDENTIFYING BRANCH ROOTS > > [[[ > $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x > Branch marker: 'subversion-source-tree' (found on both source and target) > [...] > > $ svn mergeinfo ^/subversion/trunk ^/subversion/branches > svn: E195016: Source branch marker is 'subversion-source-tree' but > target has no branch marker > > $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk > svn: E195016: Source and target are the same branch > ]]] > > This looks for a branch root marker property on the specified > directory. The property name would be 'svn:branch-root' and the value > would be a string that (more or less uniquely) identifies the > 'project' (for want of a better word) of which this is a branch. > Currently, just for testing, the property it looks for is the first > ten characters of 'svn:ignore', which tends to work moderately well > for ad-hoc testing against our own source tree because it exists and > starts with 'ChangeLog*' in the root of every branch and (I guess) > nowhere else. 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). > > 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 :-) > suggested it should only select a source automatically when it finds a > branch root marker, as that means someone has deliberately enabled the > feature. > > > MAKING MERGE EXPLAIN WHAT IT'S DOING > > [[[ > $ svn merge ^/subversion/trunk > Sync merge from '^/subversion/trunk' into '.' (a working copy of > '^/subversion/branches/showing-merge-info') > [... and maybe a summary of the revision ranges it's looking to pull in ...] > > $ svn merge --reintegrate ^/subversion/branches/showing-merge-info > Reintegrate merge from '^/subversion/branches/showing-merge-info' into > '.' (a working copy of '^/subversion/branches/trunk') > The reintegrate merge will be equivalent to: > merge ^/subversion/trunk@1188748 > ^/subversion/branches/showing-merge-info@1189710 . > [...] > ]]] > > I've only just started with this and haven't checked all of this in. > > We say that 'reintegrate' does a two-URL merge, but in wanting to make > it print what it's about to do I notice that the implementation > doesn't seem to call the two-URL merge code at all. I want to change > that and have the two phases completely separated: first the client > should figure out what merge it will do, and print that, then call the > two-URL merge code to actually do it. > > > Comments appreciated. > > - Julian >
