Re: Reduce size of repository for backup
On 2/4/11 9:39 PM, Daniel Andersson wrote: > OK, how would I go about then to completely delete the whole versioning history? One way would be to make sure all your workspaces are commited, export the head version, then start a new repository and import the directory back to it. Then delete your workspaces and check out new ones from the new repository. That's pretty drastic, though. --- Les Mikesell lesmikes...@gmail.com
Re: Reduce size of repository for backup
On 02/02/2011 09:59 PM, Les Mikesell wrote: On 2/2/11 2:47 PM, Andy Levy wrote: On Wed, Feb 2, 2011 at 15:14, Daniel Andersson wrote: Hi all, I deleted a bunch of large files from our repository yesterday that was not meant to be stored there. But these are still of course in the SVN history. I wish to do a backup each night and today I use svnadmin hotcopy for that, and rsync that hotcopy to an off-site server. I chose hotcopy since it will not cause any problems with anyone using the repository at the same time. Is it possible to delete specific large files from the history? Or do I have to dump and then delete the history all together? http://subversion.apache.org/faq.html#removal Or could I do some kind of incremental backup instead and only a full hotcopy backup each Sunday? As long as your incremental backups result in a usable repository when it's all restored, that can be done. svnadmin dump --incremental I think is what you'll need, there's no "incremental" hotcopy that I'm aware of. Or do a scheduled svnsync to a remote repository which will just pick up the updates after you get the initial copy. You might need to let it run over a weekend to get started, or make a copy locally and move it offsite. OK, how would I go about then to completely delete the whole versioning history? /Daniel
Re: Need help in restoring the svn repository (server side)
(reordering to remove top-posting) *From:* ankush chadha *To:* users@subversion.apache.org *Sent:* Fri, February 4, 2011 1:47:34 PM *Subject:* Need help in restoring the svn repository (server side) Hi All I am trying to recover the repository from a corrupted hard drive. I have very huge source repository, about 136000 revisions. Luckily I have a 4 month old backup. I think I was able to recover the contents of db/revs and db/revprops folder as it contains 136000 + 1 files each. ( 1 file per revision and a 0 revision file) There is a node-origins folder that has a bunch of files. I am not sure if I was able to fully recover files under this folder. After restoring the files, when I booted up the svn server, its reading till 133000 revisions. Its not recogizing the revisions after 133000. Does anyone know how to sync that up? Thanks AC On 2/4/2011 11:56 AM, ankush chadha wrote: Found that there is a file named 'current' that stores the HEAD revision. When I kicked off svn verify on 133001 it complained that "revisions must not be greater than the youngest revision" so I knew they stored the HEAD revision somewhere. Once I updated the value of HEAD, I can see all the revisions :) Running a svn verifier on the entire repository to make sure that nothing else is corrupted. Ankush From this I hope you (and everyone else reading this list) learned that you need to be backing up your repository much more often. Success should not be based on luck. You need to think about how much work you're willing to lose, worst-case, should your server hardware crash or otherwise go offline. Then back up more often than that. If you're not willing to lose as much as a day's worth of work then you need to backup multiple times per day, and those backups need to be copied off the server. Every night I copy my repositories using hot-backup.py, then dump the repositories and copy the dump files off the server. Once a week copies of the dump files go off-site (along with full backups of all my other data). I never have all copies of my data in the same place at the same time. The worst-case scenario is having the building catch fire as I'm doing weekly backups, taking all of the computers with it and forcing me to redo a week's work. But I can live with that; I work solo and do a couple dozen commits a week. With 136,000 revisions in your repository, you should backup your repository to a second machine multiple times per day (or use svnsync) and store at least an incremental backup of the repository off-site once per day. Think about it - you very nearly lost four months of history. Maybe your team could have reconstructed much of the changed data using giant commits from their surviving sandboxes, but that takes a lot of time and effort, is risky, and wouldn't allow you to see why the changes were made or distinguish between changes (e.g. was this line of code implementing a feature or fixing a bug?). -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
Re: Need help in restoring the svn repository (server side)
Found that there is a file named 'current' that stores the HEAD revision. When I kicked off svn verify on 133001 it complained that "revisions must not be greater than the youngest revision" so I knew they stored the HEAD revision somewhere. Once I updated the value of HEAD, I can see all the revisions :) Running a svn verifier on the entire repository to make sure that nothing else is corrupted. Ankush From: ankush chadha To: users@subversion.apache.org Sent: Fri, February 4, 2011 1:47:34 PM Subject: Need help in restoring the svn repository (server side) Hi All I am trying to recover the repository from a corrupted hard drive. I have very huge source repository, about 136000 revisions. Luckily I have a 4 month old backup. I think I was able to recover the contents of db/revs and db/revprops folder as it contains 136000 + 1 files each. ( 1 file per revision and a 0 revision file) There is a node-origins folder that has a bunch of files. I am not sure if I was able to fully recover files under this folder. After restoring the files, when I booted up the svn server, its reading till 133000 revisions. Its not recogizing the revisions after 133000. Does anyone know how to sync that up? Thanks AC
Need help in restoring the svn repository (server side)
Hi All I am trying to recover the repository from a corrupted hard drive. I have very huge source repository, about 136000 revisions. Luckily I have a 4 month old backup. I think I was able to recover the contents of db/revs and db/revprops folder as it contains 136000 + 1 files each. ( 1 file per revision and a 0 revision file) There is a node-origins folder that has a bunch of files. I am not sure if I was able to fully recover files under this folder. After restoring the files, when I booted up the svn server, its reading till 133000 revisions. Its not recogizing the revisions after 133000. Does anyone know how to sync that up? Thanks AC
Re: Inconsistent working copy state after "svn switch"
* Florian Weimer: > Switching a working copy to a branch where a locally modified file > does not exist, and switch back to the original branch (without > further changes) leaves the working copy in an inconsistent state. It > is surprisingly difficult to recover from that situation. It seems > that you have to delete the parent of the parent directory of the > affected file. > > Is this a known issue? *grr* I should have said that I saw this with 1.6.12 on GNU/Linux. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Inconsistent working copy state after "svn switch"
Switching a working copy to a branch where a locally modified file does not exist, and switch back to the original branch (without further changes) leaves the working copy in an inconsistent state. It is surprisingly difficult to recover from that situation. It seems that you have to delete the parent of the parent directory of the affected file. Is this a known issue? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Question about a fix in SVN 1.6.11
Hi, I took a look at the changes log (http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES) and found the following resolved defect in SVN 1.6.11: * fixed: theoretical possibility of DB corruption (r926151, -67) There is however no issue associated with this fix. I am wondering if I am at risk of DB corruption with my pre SVN 1.6.11 installation (which is 1.6.9). When does this problem occur. Is this only in very specific situations/configurations? Regards, Jonathan de Graaf DISCLAIMER*** Deze e-mail is uitsluitend bestemd voor de geadresseerde(n). Verstrekking aan en gebruik door anderen is niet toegestaan. De Amersfoortse Verzekeringen N.V. sluit iedere aansprakelijkheid uit die voortvloeit uit elektronische verzending. This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). De Amersfoortse Verzekeringen N.V. rules out any and every liability resulting from any electronic transmission. *
svn:externals merges
When I merge branch->trunk with directories carrying svn:externals properties the property values don't merge but report as conflicted (Note, I usually use tortoiseSVN: their mailinig list sent me here!) Is this because the property is seen as a single merge element ? Is there any workaround for 'same change' conflicts in (svn:externals) properties? Is there any way of hooking the post-merge event & fixing the externals up in user space ? -- David Kitchen InSync Technology Ltd 13B, Dragon Street Petersfield Hampshire GU31 4JN +44 (0) 1730 235 117
