Bugreport for svnadmin | svndumpfilter

2013-02-20 Thread sven . merk
Hello,

I've found a bug when dumping a certain part of an existing repository (having 
~2000 
commits, ~15 are of interest for the other one) into another existing 
repository (having 
already ~130 commits) using the following syntax (on Win7 x64):

svnadmin dump .\desktop\OldRepo --incremental | svndumpfilter include 
trunk/PathOfInterest 
--drop-empty-revs --renumber-revs | svnadmin load .\desktop\TargetRepo

The files are loaded correctly but they are associated with the wrong 
logmessages. Instead of 
the messages associated with the commits, logmessages 1-15 are loaded.

Best regards
Sven

--
Dr. Sven Merk
LTB Lasertechnik Berlin GmbH
Rudower Chaussee 29
12489 Berlin



Re: Bugreport for svnadmin | svndumpfilter

2013-02-20 Thread Stefan Sperling
On Wed, Feb 20, 2013 at 08:21:57AM +0100, sven.m...@ltb-berlin.de wrote:
> Hello,
> 
> I've found a bug when dumping a certain part of an existing repository 
> (having ~2000 
> commits, ~15 are of interest for the other one) into another existing 
> repository (having 
> already ~130 commits) using the following syntax (on Win7 x64):
> 
> svnadmin dump .\desktop\OldRepo --incremental | svndumpfilter include 
> trunk/PathOfInterest 
> --drop-empty-revs --renumber-revs | svnadmin load .\desktop\TargetRepo
> 
> The files are loaded correctly but they are associated with the wrong 
> logmessages. Instead of 
> the messages associated with the commits, logmessages 1-15 are loaded.
> 
> Best regards
> Sven

Hi Sven,

This is an interesting report, and it's quite possible that somewhere in
the command line something goes wrong.

I've tried to reproduce this problem, but failed. Log messages get loaded
as expected. Perhaps I'm doing something wrong when trying to reproduce
the problem?

Can you provide a more complete problem description? The state of your
source and destination repositories are unknown to others.

Actually, the best thing you could do to help others reproduce the problem
is provide a small script (unix shell or batch script, whichever you're
more comfortable with), that starts out by creating two empty repositories
and runs Subversion commands until the repositories have been put into the
problematic state where log messages are not what they should have been.
This will take you some time but greatly help others with finding and
fixing the bug.

Just to make sure: You are trying to reproduce this problem using the
latest stable releases (1.6.10 and/or 1.7.8)? 

Thanks!