http[s] access for svn should be looked on as purely for convenience for
quick views of files in our browser or exports and definitely should not be
relied upon for important operations like svnsync. Any other method (file,
svn, svn+ssh) will be faster and more reliable.
On Thu, Nov 19, 2009 at 11:02 AM, David Ferguson
<ferguson.david_at_gmail.com>wrote:
> Philip,
>
> We had to abandon svnsync due to the problem that you encountered. We got
> lots of "Chunk delimiter invalid" messages during sync.
>
> We instead use svnadmin dump --incremental and svnadmin load to copy over
> the data every time a commit is made. Not very elegant but it works 100% of
> the time regardless of the file size.
>
> I like Mark's idea to sync via svn:// though. The http:// protocol seems
> to be a completed dog for this replication task. I'll have to try that out.
>
> David
>
>
>
>
>
> On Wed, Nov 18, 2009 at 11:18 AM, <kmradke_at_rockwellcollins.com> wrote:
>
>>
>> Pat Farrell <pfarrell_at_pfarrell.com> wrote on 11/17/2009 10:23:40 PM:
>>
>> > Ryan Schmidt wrote:
>> > > On Nov 17, 2009, at 17:27, Pat Farrell wrote:
>> > >> I'm pretty sure that this is considered a "doctor, doctor" problem.
>> > >>
>> > > That's probably not a reasonable attitude to take for a tool like
>> > > svnsync that's supposed to be able to replicate existing
>> > > repositories. He said he already committed the large revision. We all
>> > > know there is no svnadmin obliterate and that it's difficult to
>> > > remove revisions from a repository later. And some users have valid
>> > > reasons for wanting to store large binary files in a repository.
>> > > (Video game development, for example, would involve large files for
>> > > textures, audio and video.)
>> >
>> > OK, I'll grant that, but in general, my experience is that SVN is not a
>> > great tool for large binary files. I've not worked with the specific,
>> > "svnsync" but in general, big files tend to clog up the whole process.
>> >
>> > I agree that if its supported, it should work.
>> >
>>
>> > I suggest that the svn developers consider strongly warning people that
>> > using it for big binary things is not optimal. It works well for source
>> > code, and at least "OK" for small binary things (couple of pages of Word
>> > or OpenOffice documents). But when the files get into hundreds of
>> > megabytes, for each revision, I think SVN is not the right tool.
>>
>> FWIW, our largest single revision is >20G... We don't use svnsync, but
>> you
>> are probably running into a network timeout where the client is taking
>> too long writing to disk causing the network connection to timeout before
>> it is able to request the next chunk from the server. We had to increase
>> timeout values when using http:// when using large working copies
>> with slow disk i/o on the client. Not sure where to tweak on svn://...
>>
>> Kevin R.
>>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2432214
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-12-22 07:32:13 CET