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
Received on 2016-08-10 19:08:59 CEST