[Svnmerge] questions about merge tracking

[Blair Zajac]

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 think that's a great idea.  At work, I wrote a release notes generator 
for all the commits on trunk, but it doesn't anything with the current 
log messages on a release branch with only one merge :)

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

I think have a option where one can specify the format would be handly. 
  Something like --rev-format '[%r]' and the default would be '%r' would 
be handly.

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

We have the same situation at work where we have 88 projects in a single 
repository, but I don't have a problem with merging revisions over that 
dind't affect the merging working copy.

One drawback of the proposal would be that the revision list stored in 
the branches svnmerge-integrated subversion property would then become 
sparse with only the commits on source location.  I like having that 
property being a single revision range, as it's short, the diffs on it 
are small, and it's easy to see that everythings been merged in without 
running a 'svnmerge avail'.

Regards,
Blair