Thanks for the reply!
On Mon, 03 Mar 2014 21:58:09 +0000
Philip Martin <philip.martin_at_wandisco.com> 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_at_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
Received on 2014-03-04 08:02:02 CET