To this [quote=“CaydenCM, post:9, topic:55881”]…
bring this issue to the attention of DreamHost Support:…[/quote], DreamHost (too) promptly replies:[quote]
From: DreamHost Customer Support Team email@example.com
Date: Tue, Aug 30, 2011 at 6:34 PM
Subject: Re: [… 49209965] My DreamHost Subversion now can’t add any new file over ~.5GB
- After reading this response, please consider visiting the survey below to comment on its quality. Thanks!
- If the service you received from us was exceptional, please consider tweeting your love for @dreamhost. It’ll warm our hearts, soothe our souls, and get you good karma at some point down the road.
Although Subversion will try to painstakingly chug through committing several-hundred-megabyte files, that’s really not something that Subversion handles well. If it works at all, it will take quite a while, and as you work on the repository it’s going to become slower and slower to access.
I would generally recommend storing larger files outside of Subversion for this reason. If you need to pair up particular large files with a particular revision in a Subversion repository, then you might try including revision information in the filenames of the large files and including a text file in Subversion that indicates which file revision goes with that repository revision.
If you need anything else, please let me know!
Benjamin, to be frank & in a nutshell:[list=1]
Your reply (mis)suggests you’ve helped & even solved the issue, even concluding “If you need anything else, please let me know!” (as if the issue is now closed)
when actually your reply hasn’t even answered the main Q (how to undo this new bug in DreamHost’s Subversion), indeed not even addressed this the key issue (potentially even suggesting of your boss DreamHost that DreamHost wouldn’t want to admit & face if had a new bug, something doubt they would appreciate)
and your reply makes claims which are vague (and incorrect), and without citing any sources for them, by saying what I’m asking to do won’t work (“painstakingly chug … If it works at all”)
most ironically when actually I just reported to you here, repeatedly, that not only can it work but did, repeatedly & beautifully (that is of course until this new bug at DreamHost), all of which one could essentially infer even from just reading the subject line of this thread & the bug report (“My DreamHost Subversion now can’t add any new file over ~.5GiB or .5GB”),
and also in contradiction to your claims, this is inline the official (Subversion) docs say, which I cite
 but you don’t say word to any of this (how your response completely contradicts these facts presented to you), so you did you even bother reading the bug report you’re replying to??
And you suggest an alternative solution that suggests the person posing this issue is dumb (as clearly, if s/he was using Subversion and could file a bug report as this, s/he would have thought of storing say large files outside of Subversion and could almost-certainly handle the problem of “you need to pair up particular large files with a particular revision in a Subversion repository”); and the alternative you suggest seems to suggest (probably accurately) that you are missing the very point (which was explained to you, with examples) that if the person is using Subversion for large files (as opposed to say regular WebDAV, or SFTP, or local storage), then it is because the person needs the additional features which Subversion offers (as versioning of large files, with compact binary differencing & upload) so that’s the big issue, not the much easier task of pairing up files between storage locations! Indeed, the bug report already says “this is my Subversion repository for oversized items & collections” so the person already is pairing up files.
[*]And completely ignoring my 2x request "“please post here”[/list] So instead of helping & solving the issue as your reply suggests (indeed, most arrogant of at all, even suggesting you’ve solved the key issue(!), when in fact not even addressing it, not even asking if you have solved it), instead your reply seemingly just wastes everyone’s time and angers me --with its over-confidence & technical cavalierness. Please don’t do that disrespect. Again this is a serious issue. So please read this thread carefully, and answer its Qs (especially how to undo this new bug on DreamHost); else have someone else do it who can.
Now if you gave these same answers you did with a point of view of humility & seeming-honesty, as “I don’t really know for sure and I haven’t really read the bug report, but here are some passing thoughts I have”, that would be okay (well except for probably not reading the bug report) --that is IFF you were just an ordinary user. But you are official DreamHost Support. So then, if you don’t know it or can’t handle it, you are expected to get a professional who can & will, and also learn from him/her & what they do if doing that is supposed to be your job, too.
actually that (which also contradict all the official sources & REAL EXPERIENCE I just cited to you, but you don’t say a word to this – did you even bother reading it??)
- and suggest an alternative
apparently because you seemingly didn’t carefully read this the bug report, nor really define & substantiate your claims ,
Now point-by-point, substantiating this:[list=1]I posted for you above “please post your thoughts and response & solutions here” and “please post here, especially so…”. But instead you just directly emailed me, and with not a word why you did differently. Why did you do that? As naturally then it causes me to have to repost your response (so everyone else can see it, and plus to keep all the discussion together). Did you not see what I wrote for you? I listed it 2x, including once in bold. Please just do that simple request, else explain why you cannot (that is, when I and DreamHost users are expected to post here and can do so just fine, yet somehow this is truly too hard for a DreamHost staff member).
As if you’ve solved the issue, you flippantly conclude “If you need anything else”!? Of course one would need something else! Because you didn’t answer the # question (how undo this new bug), nor even address it! Instead you’ve tried to convince me that what I want to do won’t work when, quite ironically, you seem to be missing that I am reporting to you right here that I’ve seen & experienced it work, and work beautifully, and right here on DreamHost! So did you even carefully read this thread? For yes, I wrote repeatedly, big files have worked beautifully, that is, until this bug, so please, how do we get this new bug undone?, especially when it seems to be from something DreamHost did.
But say it was true what you claim, that “Subversion will try to painstakingly chug through committing several-hundred-megabyte files, that’s really not something that Subversion handles well. If it works at all”. Then of course how would you explain what I just reported to you that’s it’s been working, & beautifully? That, to repeat, UNTIL THIS BUG, all my experience is, DreamHost Subversion handled beautifully all the big files I’ve tested it on, all the way up to my 1.2GiB .ost file, including fast & compact (8.7%) binary diffs. So either you’re not reading (my guess) or you’re telling me my measurements are false, or I’m lying. So if in fact what you’re saying is true, “if [uploading] works at all”, then, of course, how do you refute that, until this bug, it’s been working no-problem on DreamHost? And, not surprisingly, because, again, the official Subversion cite it as being scalable: “A nice feature of Subversion is that by design, there is no limit to the size of files it can handle. …” plus other references I cite. So how do explain that what you’re saying seems to conflict Subversion’s own docs?
You also write “as you work on the repository it’s going to become slower and slower to access.” --That would be interesting IF true. But how do you know that? What source do you get that? And why then is that? For, if true, this would seem to contradict the official docs suggesting Subversion is scalable. And perhaps even more importantly, it seems to contract my real experience on DreamHost Subversion (prior to this bug), where the DreamHost Subversion repository in question, primarily for holding oversized files, has now grown to 1,616,210,482 grown now grown to And I have a hard time believing you really know that. Because when you write me “If [the upload] works at all” after I’ve just reported to you that it has BEEN working beautifully, then it sounds like you’re not reading and just guessing, wasting everyone’s time.
Also you write “I would generally recommend storing larger files outside of Subversion for this reason…” --okay, then how to protect against the files being accidentally/intentionally modified or deleted, as Subversion solves? And, how to compactly version them & upload the differences, Subversion solves? I need the these features of Subversion (compact differencing & differencing upload & storage, keeping ideally unlimited version, and being able to undo-else-prevent any modification or deletion, plus private storage). So how to solve that?
You write “If you need to pair up particular large files with a particular revision in a Subversion repository, then you might try including revision information in the filenames” --how dumb do you think I am? Would you not think if someone uses Subversion.
[*]But most important, please get answered my key question: why is this bug now & how can it get fixed?
As this thread asks, please give specific
[So first please read this thread, Yes, it’s long, in particular because it may be hard for many people (as perhaps yourself) to believe, but it’s true.