Yikes, something is wrong with the data you sent me.  Are you able to
load that dumpfile into an empty repository?

$ svnadmin create newrepos
$ svnadmin load newrepos < foo.dump


...on revision 2, it fails for me!

...
     * adding path : trunk/apps/qubit/modules/admin/actions ... done.
     * adding path :
trunk/apps/qubit/modules/admin/actions/actions.class.php ... done.
     * adding path : trunk/apps/qubit/modules/admin/templates ... done.
subversion/libsvn_fs_fs/dag.c:1018: (apr_err=200014)
svnadmin: Checksum mismatch, file
'/trunk/apps/qubit/modules/admin/templates/disabledSuccess.php':
   expected:  3b23e4725b3fe26743ae8ab29fac3d5c
     actual:  4c89a13b6df5760121596ece48cb69ca




On Wed, Mar 18, 2009 at 2:19 PM, Jack Bates <[email protected]> wrote:
>
> Done - here is a 62M "svnadmin dump" with --deltas:
> http://cgi.sfu.ca/~jdbates/tmp/google/200903180/svn-20090318.dump
>
> On Mar 17, 7:47 pm, Ben Collins-Sussman <[email protected]> wrote:
>> Well yes, I would.  It means I'd have to spend half as long downloading.  :-)
>>
>> On Tue, Mar 17, 2009 at 4:16 PM, Jack Bates <[email protected]> wrote:
>>
>> > Thanks, here is a 257M "svnadmin dump" of the repository:
>> >http://cgi.sfu.ca/~jdbates/tmp/google/200903170/svn-20090317.dump
>>
>> > If you would actually prefer a zipped tarball of the repository, or a
>> > dump file using --deltas, or something else, just let me know...
>>
>> > On Mar 17, 11:11 am, Ben Collins-Sussman <[email protected]> wrote:
>> >> What would be most useful is if I could try reproducing the error
>> >> myself.  Can you zip up the repository somewhere and post it?  Then I
>> >> can suck it down to local disk and trying syncing it myself.
>>
>> >> On Tue, Mar 17, 2009 at 1:08 PM, Jack Bates <[email protected]> wrote:
>>
>> >> > I am always observing it fail on a DELETE request. I have noticed that
>> >> > it is a different file each time, but the number of "Transmitting file
>> >> > data" dots is always about the same: Five or six rows in my 80x24
>> >> > terminal.
>>
>> >> > It is hard to be accurate about the time - thirty minutes was my
>> >> > guess, but actually I think it stops printing dots after about fifteen
>> >> > minutes, but does not print the error and terminate for an hour or
>> >> > two. I can say confidently that I have never observed it take a
>> >> > radically different amount of time, like five minutes.
>>
>> >> > If it would be useful, I can try being more accurate, by running
>> >> > "date; svnsync sync ...; date", and seeing how consistent the timing
>> >> > is. Alternatively, I am happy to take any action you can suggest, to
>> >> > gather more timing or other debugging information?
>>
>> >> > On Mar 17, 9:41 am, Ben Collins-Sussman <[email protected]> wrote:
>> >> >> Just to verify:  it always takes about 30 mins?  It always fails on a
>> >> >> different file?   (Is it always a DELETE request that fails?)
>>
>> >> >> On Tue, Mar 17, 2009 at 11:25 AM, Jack Bates <[email protected]> 
>> >> >> wrote:
>>
>> >> >> > Thanks, I ran it again since your message, to check, and observed the
>> >> >> > same behavior and output:
>>
>> >> >> > amos% svnsync synchttps://qubit-toolkit.googlecode.com/svn
>> >> >> > Transmitting file
>> >> >> > data 
>> >> >> > .........................................................................................................................................................................................................................................................................................................................................................................................................................svnsync:
>> >> >> > DELETE of 
>> >> >> > '/svn/!svn/wrk/e8d9e9b8-4d8f-46ea-aaaf-3216c81c0bad/branches/
>> >> >> > ica-atom/lib/vendor/symfony/lib/widget/
>> >> >> > sfWidgetFormSelectCheckbox.class.php': SSL negotiation failed: SSL
>> >> >> > error: GnuTLS internal error. (https://qubit-toolkit.googlecode.com)
>> >> >> > amos%
>>
>> >> >> > More ideas?
>>
>> >> >> > On Mar 16, 5:35 pm, Ben Collins-Sussman <[email protected]> wrote:
>> >> >> >> Is this still happening *today*?  You say it started failing last
>> >> >> >> week, but last week we had a (temporary) bug where long-lasting
>> >> >> >> requests were timing out.
>>
>> >> >> >> On Mon, Mar 16, 2009 at 5:26 PM, Jack Bates <[email protected]> 
>> >> >> >> wrote:
>>
>> >> >> >> > We have been merrily using svnsync to mirror our Subversion 
>> >> >> >> > repository
>> >> >> >> > to Google project hosting for over a year. Last week it stopped
>> >> >> >> > working.
>>
>> >> >> >> > I found a stale lock:
>>
>> >> >> >> > amos% svnsync synchttps://qubit-toolkit.googlecode.com/svn
>> >> >> >> > Failed to get lock on destination repos, currently held by
>> >> >> >> > 'amos:dd546213-371d-4251-96bf-36b10b734040'
>> >> >> >> > [...]
>>
>> >> >> >> > - and used the command from the svnsync notes to delete it:
>> >> >> >> >http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt
>>
>> >> >> >> > amos% svn pdel --revprop -r 0 
>> >> >> >> > svn:sync-lockhttps://qubit-toolkit.googlecode.com/svn
>> >> >> >> > property 'svn:sync-lock' deleted from repository revision 0
>> >> >> >> > amos%
>>
>> >> >> >> > - but every time I re-run svnsync, I get the same output:
>>
>> >> >> >> > amos% svnsync synchttps://qubit-toolkit.googlecode.com/svn
>> >> >> >> > Transmitting file
>> >> >> >> > data .........................................................
>> >> >> >> > ................................................................................
>> >> >> >> > ................................................................................
>> >> >> >> > ................................................................................
>> >> >> >> > ................................................................................
>> >> >> >> > ................................svnsync: DELETE of '/svn/!svn/wrk/
>> >> >> >> > 303f195a-9bba-
>> >> >> >> > 4fdc-a08a-811cb2a19578/branches/ica-atom/lib/vendor/symfony/test/
>> >> >> >> > functional/fixt
>> >> >> >> > ures/project/apps/frontend/modules/view/templates': SSL 
>> >> >> >> > negotiation
>> >> >> >> > failed: SSL
>> >> >> >> > error: GnuTLS internal error. 
>> >> >> >> > (https://qubit-toolkit.googlecode.com)
>> >> >> >> > amos%
>>
>> >> >> >> > - though it sometimes stops at different file names.
>>
>> >> >> >> > Because svnsync runs for about thirty minutes before this error is
>> >> >> >> > printed, I thought it might be a timeout? Any idea how to get our
>> >> >> >> > Subversion repository synchronizing with Google project hosting 
>> >> >> >> > again?
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Hosting at Google Code" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-code-hosting?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to