On Wed, Jun 02, 2010 at 11:33:21AM +0200, B Smith-Mannschott wrote:
> A few clever people suggested a way around the delete-and-recreate the
> branch problem. Just use a record-only merge to make the topic branch
> aware of the reintegration revision on trunk without actually enduring
> the resulting conflicts.
>
> It sounded like a great idea when I read it. Very clever.
>
> Unfortunately, it's also *very* *broken*.
>
> This technique interacts badly with "svn log -g". After a few repetitions of
> merge, merge --record-only, merge --reintegrate, I'm finding the same
> revisions showing up over and over again in my trunk when using svn log -g.
>
> svn log -q | wc -l
> 2299
>
> svn log -q -g | wc -l
> 14167
>
> $ svn log -q -g | egrep -o -e "^r[0-9]+" | sort | uniq -c | sort -n | tail
> 131 r42278
> 135 r42171
> 135 r42251
> 135 r42252
> 136 r42196
> 136 r42205
> 136 r42219
> 136 r42223
> 191 r42282 <-- these two revisions appear 191 times in the log -g of trunk!
> 191 r42292 <--
>
> When this has made svn log -g useless for me. ("Include merged
> revisions" in TortoiseSVN is similarly useless). This is unfortunate,
> because I had hoped that this feature would free me from having to
> painstakingly protocol which revisions were merged in the log message
> as I used to do in 1.4 days.
On the surface, this doesn't look like a merge-tracking problem.
It smells more like a presentation-layer bug (in log -g).
We should figure out how log -g should behave in this case (the behaviour
you're seeing clearly isn't desirable) and then fix it.
Please file an issue.
BTW, there's another known problem with the --reintegrate/--record-only trick,
with 2-URL merges: http://subversion.tigris.org/issues/show_bug.cgi?id=3648
Thanks,
Stefan
Received on 2010-06-02 12:37:55 CEST