I tried the patch but unfortunately is not working for me.
I'll try to reproduce the error in a smaller repository.
What I don't understand is if the problematic revision is the 1306 or 1307.
The error message reefers to 1306 but I can see in the logs of the synced
repository that the 1306 revision seems to be already imported. On the other hand,
the revision 1307 is a large merge that looks much more suspicious to me.
Is the revision number displayed during the sync zero based? Or is the synced repository
in an inconsistent state?
On Jul 6, 2010, at 3:32 PM, Daniel Shahaf wrote:
> Juan Wajnerman wrote on Mon, 5 Jul 2010 at 18:13 -0000:
>> I'm trying to perform a svnsync with a repo stored at Google Code but
>> it always fails at certain revision with the following error:
>>
>> $ svnsync sync file:///~/Riff Transmitting file data
>> ...........svnsync: File not found: transaction '1306-10e', path
>> '/trunk/Modules/ReadUnread/Source/ReadUnread.Web/Controllers/ReadUnreadController.cs'
>>
>> To reproduce this error, just try the same svnsync with the repo
>> located at http://riff-evolve.googlecode.com/svn.
>>
>> I found a similar issue in the bug database
>> (http://subversion.tigris.org/issues/show_bug.cgi?id=3641) but
>> I cannot see the reason described there matches with my case. What
>> I can see as suspicious is that in the problematic revision a branch
>> is created with the same name as an old branch that was deleted in
>> a previous changeset.
>>
>
> The patch I posted to #3641 handles the case of replaces (i.e., a remove
> and an add-with-history of a path in the same revision). This "same name
> as an old branch" issue, therefore, rings a bell... Can you try that patch?
>
> Alternatively, it would probably be helpful if you could come up with a
> smaller reproduction repository (i.e., one that uses fewer than 1300
> revisions, and modifies few files in each revision). Can you narrow the
> problem down?
>
>> I'm currently using Subversion 1.6.5 (r38866) with Mac OSX 10.6.4.
>>
>> Any hint will be appreciated, even a workaround to this problem.
>>
>> Thanks, - Juan
>>
>>
>>
>>
>>
Received on 2010-07-08 16:26:00 CEST