[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnsync will not sync 527Mb revision

From: Pat Farrell <pfarrell_at_pfarrell.com>
Date: Tue, 17 Nov 2009 23:23:40 -0500

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.

All IMHO of course.

There are times when I would love your "svnadmin obliterate"

-- 
Pat Farrell
http://www.pfarrell.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2419303
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-18 05:24:52 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.