Nico, >>> I have attemped svnadmin dump, svnadmin hotcopy and svnrdump. I am >>> getting the error before from all these utilities > > Break it up. Use svnadmin dump for 1000 commits at a time, to help > isolte if it's a specific commit that is killing you or if perhaps you > are running out of resources for such a large dump > Thanks for this suggestion. Its precisely what I did and was able to dump the full repo successfully. Well, now that I did look at the logs, not too cleanly. I have a lot of warnings like this:
* Dumped revision 2062. WARNING 0x0000: Referencing data in revision 1696, which is older than the oldest dumped revision (r2001). Loading this dump into an empty repository will fail. * Dumped revision 3000. WARNING 0x0000: The range of revisions dumped contained references to copy sources outside that range. WARNING 0x0001: Mergeinfo referencing revision(s) prior to the oldest dumped revision (r57001). Loading this dump may result in invalid mergeinfo. What would this imply? > In particular, 113 GB is pretty bulky. It's probably a good time to > think about trimming away some of the fat, of old branches and tags > that are no longer needed, or even to think about splitting the repo > up into smaller, individual projects. If that can be trimmed away to > proper use of svndumpfilter, more power to you. This violates the > tenet that the history, all of it, is the important thing, but I'm not > personally a big believer in it., > Thanks, was planning to break it into smaller repos, but the process hasn't been smooth, so for now, just want a simple dump and restore to work first. > There are also several nasty approaches to get something working > *now*, in parallel with your old repository. One is to do svn > export/import of the relevant code in a new working repository: you'd > need to reconcile the inevitable split brain after you get the full > repository copied, but if you're out of time it can save your ass. > (And yes, I'm bringing it up again, even though it consistently gets > me yelled at.) Thats an interesting advice.. I can see the pain involved due to split brain, but since the current repo is working, I think its better to avoid this. But definally a great advice for firefighting > > There is also a nasty, but in a pinch workable, trick for getting > similar end results for unsophisticated repositories to get code up > and running if you're out of time. If you're not worried about > preserving svn:keywords, svn:ignore, or other added repository > attributes, you can get a fast clone working when svnadmin is giving > troubling by using git. > > * Use "git svn" to make a "fast" copy. > * Delete unwanted debris, such as unuseful tags and branches. > * Use "git gc" to obliterate content that is no longer used. > * Use "git svn" to upload the content to a new, *much smaller* working > repository. > > This flushes a great deal of attribute information and potentially > useful history, but it's often a much faster way to clear excess > debris and get a new, non-identical, but workable Subversion > repository with most of the important content history intact. > Interesting.. If I am not able to restore, I may just end up using this.. I will leave it as last option and will have to see if everybody can stomach it.. Thanks for sharing all this knowledge. William
