Re: How to recover from "Found malformed header in revision file"?
Any update on this? Did svnsync fix your issue? I am receiving the same error when trying to dump a 46 gb repo * Dumped revision 1703. * Dumped revision 1704. * Dumped revision 1705. svnadmin: Malformed representation header svnhotcopy only copies about 6gb of the repo! (I am using version 1.4.0 (r21228)) Any ideas? I was thinking about trying svnsync but there is a bug in that version where i cannot do svnsync over https without accepting the certificate every time. On Mar 8, 12:25 pm, Steven Roussey wrote: > I can do a full checkout at the moment. Too bad I can't go from that > and create a new repo. Anyhow, the svnsync idea is a good one, and > I'll have to give that a try. Thanks! > > Steven Roussey > Network54 Corp. > > 2010/3/3 Mariusz Droździel : > > > On 4 March 2010 03:24, Steven Roussey wrote: > > >> I also tried svnadmin recover which did not work, and fsfsverify.py. I > >> have a > >> few working copies around that are ok (I think) -- is there a way to use > >> that to > >> fix the repository? > > > Check out "Corrupted FSFS commit" and "Broken Revision in FSFS Repo" > > threads from few days ago. I think me and Martin had very similiar > > problem and solved it out with svnsync + access control over webdav. > > > -- > > Mariusz Drozdziel > >
Re: How to recover from "Found malformed header in revision file"?
I tried using svnsync because i receive the malformed header error when attempting to dump my repo. Svnsync fails after eight revisions (SVN version 1.4.0 (r21228)) Console output: ... Committed revision 8. Copied properties for revision 8. Committed revision 9. Copied properties for revision 9. svnsync: REPORT request failed on 'https://' svnsync: REPORT of 'https://': 200 OK (https://) On Apr 13, 1:05 pm, Stonebraker wrote: > Any update on this? Did svnsync fix your issue? > > I am receiving the same error when trying to dump a 46 gb repo > * Dumped revision 1703. > * Dumped revision 1704. > * Dumped revision 1705. > svnadmin: Malformed representation header > > svnhotcopy only copies about 6gb of the repo! > > (I am using version 1.4.0 (r21228)) > > Any ideas? I was thinking about trying svnsync but there is a bug in > that version where i cannot do svnsync over https without accepting > the certificate every time. > > On Mar 8, 12:25 pm, Steven Roussey wrote: > > > I can do a full checkout at the moment. Too bad I can't go from that > > and create a new repo. Anyhow, the svnsync idea is a good one, and > > I'll have to give that a try. Thanks! > > > Steven Roussey > > Network54 Corp. > > > 2010/3/3 Mariusz Dro¼dziel : > > > > On 4 March 2010 03:24, Steven Roussey wrote: > > > >> I also tried svnadmin recover which did not work, and fsfsverify.py. I > > >> have a > > >> few working copies around that are ok (I think) -- is there a way to use > > >> that to > > >> fix the repository? > > > > Check out "Corrupted FSFS commit" and "Broken Revision in FSFS Repo" > > > threads from few days ago. I think me and Martin had very similiar > > > problem and solved it out with svnsync + access control over webdav. > > > > -- > > > Mariusz Drozdziel > >
SVN Migration using tar only, is this possible (without dump or hotcopy)?
I need to move a few very large repositories (one over 30 GB) to another server (both servers use SVN 1.4.0.) Server 1: FreeBSD 6.0 Server 2: Windows Server 2003 x64 Transfer method: NFS (Network File Share) Are there any issues with just tarring up the repositories and transferring them over NFS to my destination server (assuming no one commits anything) then doing a setuuid and moving over the user database? Will this scenario work? 1. Tar repository (assume there are no commits during tar) 2. Transfer .tar to destination server 3. untar 4. transfer svn user database to destination (modify config files so svn knows path) 5. setuuid on repo Note: I am unable to use svnadmin dump or hotcopy (both error out.. which is why i'd like to pursue this). Thank you, I really appreciate it!
Re: SVN Migration using tar only, is this possible (without dump or hotcopy)?
Hi Ryan, I really appreciate your input on this, thank you. > Probably not recommended. Repositories are not meant to be portable, but > dumpfiles are. Though note dumpfiles do not include anything other than the > revisions. In particular dumpfiles do not include hook scripts or > configuration files; these must be transferred separately. I would love to dump/hotcopy/svnsync these repos over but they all encounter errors with those commands. I'd prefer to just disallow all connections to the repo, tar+lzop, transfer over to destination server and hook it up to same version of svn. I'm thinking that in theory this should work (as long as svn is configured exactly the same on both servers)... I guess i'm just looking for someone to say, "yeah that might work". > Could you describe the error in more detail? When I attempt to dump a 46 gb repo ... # * Dumped revision 1703. # * Dumped revision 1704. # * Dumped revision 1705. # svnadmin: Malformed representation header svnhotcopy only copies about 6GB out of 46GB of the repo! Svnsync fails after eight revisions ... # ... # Committed revision 8. # Copied properties for revision 8. # Committed revision 9. # Copied properties for revision 9. # svnsync: REPORT request failed on 'https://' # svnsync: REPORT of 'https://': 200 OK (https://) svnadmin verify also errors out >"Note that Subversion < 1.5 is not supported anymore. Please upgrade if >possible. " I would love to upgrade from version 1.4.0 (r21228) but a number of repos error out when I attempt to dump/svnhotcopy/svnsync I encounter errors. At this point we are just going to run a legacy 1.4.0 server (on my destination server) and the latest visual svn (and just start from scratch with all new repos). My goal is to just move these old repos to the destination server by whatever means possible (and as of right now... the aforementioned commands aren't working). thank you so much! On May 13, 2:41 am, Ryan Schmidt wrote: > On May 13, 2010, at 02:35, Stonebraker wrote: > > > I need to move a few very large repositories (one over 30 GB) to > > another server (both servers use SVN 1.4.0.) > > Note that Subversion < 1.5 is not supported anymore. Please upgrade if > possible. > > > > > Server 1: FreeBSD 6.0 > > Server 2: Windows Server 2003 x64 > > Transfer method: NFS (Network File Share) > > > Are there any issues with just tarring up the repositories and > > transferring them over NFS to my destination server (assuming no one > > commits anything) then doing a setuuid and moving over the user > > database? > > > Will this scenario work? > > 1. Tar repository (assume there are no commits during tar) > > 2. Transfer .tar to destination server > > 3. untar > > 4. transfer svn user database to destination (modify config files so > > svn knows path) > > 5. setuuid on repo > > Probably not recommended. Repositories are not meant to be portable, but > dumpfiles are. Though note dumpfiles do not include anything other than the > revisions. In particular dumpfiles do not include hook scripts or > configuration files; these must be transferred separately. > > > Note: I am unable to use svnadmin dump or hotcopy (both error out.. > > which is why i'd like to pursue this). > > Could you describe the error in more detail? > > Have you already run "svnadmin verify"? Does it succeed without error?
Re: SVN Migration using tar only, is this possible (without dump or hotcopy)?
Thanks for the response. It sounds like it would be better to move the corrupt repos to another *nix (instead of windows). My new plan is to move the corrupt SVN 1.4.0 repos (on the FreeBSD 6.1- RELEASE machine)via TAR + NFS to a Red Hat Linux 5.3 box (with SVN 1.4.0). If I can get them there and hooked up in the same state they are in now, that's good enough. svnadmin verify fails with this message "malformed representation header". From what i've read about it... " There is no fix without possible data loss. The only thing we could do is dump the repository till the repository is Ok then use svnadmin dump --incremental -r :HEAD You can examinie the broken revision with svnlook." any suggestions related to the tar + transfer between the freebsd and red has linux box would be appreciated. On May 13, 11:08 pm, Ryan Schmidt wrote: > On May 13, 2010, at 10:47, Bob Archer wrote: > > >> I would love to upgrade from version 1.4.0 (r21228) but a number of > >> repos error out when I attempt to dump/svnhotcopy/svnsync I encounter > >> errors. > > >> At this point we are just going to run a legacy 1.4.0 server (on my > >> destination server) and the latest visual svn (and just start from > >> scratch with all new repos). My goal is to just move these old repos > >> to the destination server by whatever means possible (and as of right > >> now... the aforementioned commands aren't working). > > > Ouch. Have you tried to just upgrade your existing servers to 1.6.11? The > > newer version of dump or hotcopy or svnsync might work without upgrading > > the old repository. Of course you can upgrade it inplace using svnadmin > > upgrade. But, if that fails you will need to restore the repo... (I expect) > > > As far as just moving the repository folders from one to the other... I'd > > say give it a shot. Most of what I have read and heard is that will work if > > you are staying on the same OS and architecture but has problems if you try > > to move from one to the other... for example, Linux to Windows... not > > recommended without using dump/load. > > He already stated that he is moving from FreeBSD to Windows Server. > > I would strongly advise correcting the problems encountered by svnadmin > verify before attempting to move the repository to a different server. The > fact that svnadmin verify does not complete successfully is a pretty good > indicator that the repository *is* corrupt at this point, and moving to a new > machine will, at best, leave the repository as corrupt as it is now.
