[Svnmerge] Log of merges

[Giovanni Bajo]

Archie Cobbs <archie at dellroad.org> wrote:


>> a GCC branch maintainer has asked me for a way to tell svnmerge
>> "jump me back 3 merges ago". While I believe that calling "svn up"
>> is a bit too much for svnmerge, this request gave me an idea for a
>> new feature: we could implement a "svnmerge log" command which
>> shows the list of all merges happened in the branch. This would
>> allow to easily implement the jump-back command as a wrapping
>> script (or give the basis to code it within svnmerge, if we want it
>> there).

> First of all, what does "jump me back 3 merges ago" mean? There
> are a couple of interpretations.
>
> If the desire is to revert the past N merges (but not any intervening
> non-svnmerge commits), my first thought would be to use the normal svn
> mechanism for this: review the log, then "svn merge" the reversed
> changes. Note that this will revert the svnmerge-integrated property
> as well.
>
> If the desire is simply to update to a prior revision, "svn up -r ..."
> works just fine...


I'll have to further investigate the needs of the maintainer. What I have
understood is that, using svnmerge, he looses what he considers a valuable
information, that is the multiple merge tags. With CVS, they were always around
for obvious reasons, and he often uses the last 3/4 merge tags for diff
operations and whatnot. I believe the typical questions are: "what was changed
in this file since last merge?", "if I rollback to immediately after last
merge, does this bug show up? What if I go back two merges? Or three?".

With CVS, you could answer this with things liks "cvs
diff -rMYBRANCH_MERGE_20051022 foo.c", and "cvs up -rMYBRANCH_MERGE_20051014
foo.c". You can almost do the same if you use multiple merge tags with SVN (the
required command line is much longer, and this is being discussed right now in
the dev subversion mailing list). With svnmerge, one has to manually inspect
the full log of the branch to find the wanted revision numbers, and use those
numbers. This is much more burdesome, especially if compared to a "svn ls" to
get the merge tag names.

This is why I was proposing "svnmerge log": we do the tedious work of finding
out the merges, and show those.

Giovanni Bajo