[Svnmerge] questions about merge tracking

[Jim Fulton]

Giovanni Bajo wrote:
> Hello,
> 
> I began using svnmerge for some real development (I'm using my Python
> version, so I hope some of the below issues are not just bugs on my side). I
> have some questions and ideas for enhancements:
> 
> - The "svnmerge merge" commit message (produced by -f) could be more
> informative. For instance, it could also report the original logs of the
> revisions merged in. Otherwise, running "svn log" in the branch produces a
> totally uninformative list of other revision numbers to look at. Opinions?
> If we add this, should it be the default? Should there be an option to
> enable/disable it?

I'm for making the more informative log the default.  +1

> - I'm using Trac for my projects, so I would not mind having hyperlinks
> working in my commit messages. It is sufficient to put revision numbers in
> squares (eg. [345]). I understand this is not something everybody will want,
> so I was wondering about adding an option for it. Of course, I could write
> an external script "tracify.py" to post-process commit.txt, but I figured I
> would ask if there is interest in such an option.

Could you be more specific about what you're proposing?

> - Currently, when you run "svnmerge avail", it gets the latest revision in
> the head, and assumes that the range 1:HEAD_REVISION, subtracted with all
> the ranges which are already merged, are all revisions available for
> merging. This is of course not true: in that range, there might be many
> commits done on other branches which have nothing to do with either our
> branch nor the trunk. In one setup, I keep many totally different projects
> within the same subversion repository, so assuming that every commit
> happened to head is absolutely suboptimal. In fact, the merge itself will be
> done through a commit, and that very commit will be shown in "svnmerge
> avail" next time you run it (after another commit on head).
> So, I believe that "svnmerge avail" should only show commits which happened
> on head. To do this, it could invoke "svn log
> head -rXX:HEAD --stop-on-copy", where XX is the latest integrated revision.
> Then, it could parse the output to extract the revision numbers. I quickly
> tried with: svn log --stop-on-copy --xml | grep -P 'revision="\d+"' and it
> seems to be feasable.
> Comments?

This is one of the things I wanted to do in my version. +1

Jim