[Svnmerge] questions about merge tracking

[Archie Cobbs]

Giovanni Bajo wrote:
> 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?

This has occurred to me too. Would make for a nice optional feature
you could enable with a command line flag.

> - 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.

Sounds a little too specific. How about an option to run a script to
generate the commit message? The script would be passed the relevant
info (revisions, etc.) on the command line.

> - 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?

I'm assuming you would take your XX:HEAD list and combine it with: the
1:XX list after subtracting out already-merged revisions (i.e., from the
svnmerge-integrated property)... otherwise you'd not show the unmerged
revisions < XX. By induction, that list would also be "pruned"...

If so then this makes sense. You'd only need to do it for the normal
(non "-l" or "-d") cases of "svnmerge avail". It make make things run
slower though.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com