Thanks for the reply! On Mon, 03 Mar 2014 21:58:09 +0000 Philip Martin <[email protected]> wrote: > I think the code attempts to classify which parts of the merge are > direct and indirect but it ends up adding extra changes. If you run the > log in different directions then different results are obtained: > > $ svn log -qg -r0:head file:///tmp/repo_test/trunk > ... > --------------------------------------------------------------------- > --- r9 | pm | 2014-03-03 21:00:15 +0000 (Mon, 03 Mar 2014) > Merged via: r10 > --------------------------------------------------------------------- > ---
Yes, I have also noted that it is possible to get that information by doing: svn log -qg file:///tmp/repo_test/trunk@10 or simply svn log -qg -r 10 file:///tmp/repo_test/trunk My guess however, is that going in the opposite direction helps in this case where there are only two merges into trunk, but maybe other merges would be hidden both ways if there were more merges into trunk? I still don't get it when exactly merge information is lost. > The change made on branches/1 in r9 is merged to trunk in r10: ... Yes, in my example there are 4 merges total. One merge from trunk to each branch and one merge back to trunk for each branch. I think that at least one of the merges from trunk to branch and the order in which the merges are done matter whether the "log -g" will miss a merge. I have also seen other examples where merges to branches are lost from "log -g". > There is also this: > > $ svn log -qg -c12 file:///tmp/repo_test/trunk > ... > --------------------------------------------------------------------- > --- r9 | pm | 2014-03-03 21:00:15 +0000 (Mon, 03 Mar 2014) > Merged via: r12, r11, r10 > --------------------------------------------------------------------- > --- > > which shows 3 revisions in the via list, i.e. both paths. Yes, that one seems to behave the same between older versions of svn and newer versions of svn. However, I would prefer to read entries like ------------------------------------------------------------------------ r10 | henca | 2014-03-04 07:48:48 +0100 (Tue, 04 Mar 2014) ------------------------------------------------------------------------ r9 | henca | 2014-03-04 07:48:45 +0100 (Tue, 04 Mar 2014) Merged via: r10 ------------------------------------------------------------------------ ...as they are rather easy to understand. I have written a tool svn2cvsgraph http://svn2cvsgraph.sourceforge.net/ which helps to visualize the revision graph of a svn repository. With older versions of svn, it was possible to get all the merge information I needed from a single (slow) call to "svn log -qg file:///tmp/repo_test", with newer versions I instead make one such (quicker) call for every branch. That is also backwards compatible with older versions of svn which is somewhat slower, but on the other hand those logs do not miss any merge entries. I could rewrite my tool to do one call for each revision, but that would be slow, and it seems to me as if there is something broken with "svn log -g" when some merge information is missing. regards Henrik
