RE: check out deleted folder
Hi there, my situation is as follows: there's a large svn repository svn+ssh://someserver/reps/maindir/ I only work with the subdirectory svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with such that I used to check it out with svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with what_I_work_with got moved by the maintainers of the main repository in revision r123456 to svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with now I can check it out with svn co svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with in newlocation, commands like svn log, svn blame, ... still work, I see commit messages from before r123456 and changes from r900 are correctly reported by svn blame. what does not work is cd what_I_work_with svn up -r900 since maindir/new_dir/foobar/what_I_work_with doesn't exist in r900. Also the alternate approach checking out what_I_work_with doesn't work since the directory doesn't exist in the trunk svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with neither did switching work: cd what_I_work_with svn switch /old_dir/... Also, I'm hesitant to check out svn+ssh://someserver/reps/maindir due to the large overhead of stuff in there which I don't need (in fact I found it a strong part of svn that subdirectories of a repository are repositories themselves). Is there any way to check out or update to revision r900? I don't think so. Since the canonical name of an item in the repository is a combination of the full path and the rev number (^maindir/new_dir/foobar/what_I_work_with@123456) you can't update a path to a revision in which that path didn't exist. You would have to check out rev900 from the original path. You could try: Svn co -r 900 ^maindir/new_dir/foobar/what_I_work_with@123456 But, I'm not sure if that will work. BOb
RE: check out deleted folder
Hi there, my situation is as follows: there's a large svn repository svn+ssh://someserver/reps/maindir/ I only work with the subdirectory svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with such that I used to check it out with svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with what_I_work_with got moved by the maintainers of the main repository in revision r123456 to svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with now I can check it out with svn co svn+ssh://someserver/reps/maindir/new_dir/foobar/what_I_work_with in newlocation, commands like svn log, svn blame, ... still work, I see commit messages from before r123456 and changes from r900 are correctly reported by svn blame. what does not work is cd what_I_work_with svn up -r900 since maindir/new_dir/foobar/what_I_work_with doesn't exist in r900. Also the alternate approach checking out what_I_work_with doesn't work since the directory doesn't exist in the trunk svn co svn+ssh://someserver/reps/maindir/old_dir/foobar/what_I_work_with neither did switching work: cd what_I_work_with svn switch /old_dir/... Also, I'm hesitant to check out svn+ssh://someserver/reps/maindir due to the large overhead of stuff in there which I don't need (in fact I found it a strong part of svn that subdirectories of a repository are repositories themselves). Is there any way to check out or update to revision r900? I don't think so. Since the canonical name of an item in the repository is a combination of the full path and the rev number (^maindir/new_dir/foobar/what_I_work_with@123456) you can't update a path to a revision in which that path didn't exist. You would have to check out rev900 from the original path. You could try: Svn co -r 900 ^maindir/new_dir/foobar/what_I_work_with@123456 But, I'm not sure if that will work. BOb Oh, and you can of course check out the deleted path... just provide the peg revision... Svn co ^path/to/file@900 BOb
Re: check out deleted folder
On Wed, Jul 24, 2013 at 05:04:13PM +0200, Paul Seyfert wrote: Is there any way to check out or update to revision r900? Do you know about peg revisions? http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
Re: check out deleted folder
Oh, and you can of course check out the deleted path... just provide the peg revision... Svn co ^path/to/file@900 BOb Hi, @BOb Thanks! Exactly what I needed! @Stefan no I didn't know about peg revisions. Thanks for the pointer! Paul
Apache Subversion 1.7.11 released
I'm happy to announce the release of Apache Subversion 1.7.11. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#supported-releases This release addresses one security issue: CVE-2013-4131: mod_dav_svn assertion from requests against root path. More information on these vulnerabilities, including the relevent advisories and potential attack vectors and workarounds, can be found on the Subversion security website: http://subversion.apache.org/security/ The SHA1 checksums are: e57f89818af67a7d6e1707f3612736bbe8ba4f0d subversion-1.7.11.tar.gz e7b29fd29b757906e6a88274455d24ea7e326d29 subversion-1.7.11.zip d82e187803043b74c072cd5a861ac02e4a027684 subversion-1.7.11.tar.bz2 PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.7.11.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.7.11.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.7.11.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [2048R/9A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 Release notes for the 1.7.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.7.html You can find the list of changes between 1.7.11 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.7.11/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Apache Subversion 1.8.1 released
I'm happy to announce the release of Apache Subversion 1.8.1. Please choose the mirror closest to you by visiting: http://subversion.apache.org/download/#recommended-release This release addresses one security issue: CVE-2013-4131: mod_dav_svn assertion from requests against root path. More information on these vulnerabilities, including the relevent advisories and potential attack vectors and workarounds, can be found on the Subversion security website: http://subversion.apache.org/security/ The SHA1 checksums are: 12261a97df5cdc53175cba813ea451937a226bca subversion-1.8.1.zip 7705819a0037c14fb32eef36f2e57a803217c689 subversion-1.8.1.tar.bz2 2abad4b9db4e236890d687f24b8dee7bee52cc2a subversion-1.8.1.tar.gz PGP Signatures are available at: http://www.apache.org/dist/subversion/subversion-1.8.1.tar.bz2.asc http://www.apache.org/dist/subversion/subversion-1.8.1.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.8.1.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F 4B8A 43FD 6525 919F 6F61 F6AD 8147 Johan Corveleyn [4096R/010C8AAD] with fingerprint: 8AA2 C10E EAAD 44F9 6972 7AEA B59C E6D6 010C 8AAD Paul T. Burba [4096R/56F3D7BC] with fingerprint: 1A0F E7C6 B3C5 F8D4 D0C4 A20B 64DD C071 56F3 D7BC Philip Martin [2048R/ED1A599C] with fingerprint: A844 790F B574 3606 EE95 9207 76D7 88E1 ED1A 599C Stefan Sperling [2048R/9A59B973] with fingerprint: 8BC4 DAE0 C5A4 D65F 4044 0107 4F7D BAA9 9A59 B973 Release notes for the 1.8.x release series may be found at: http://subversion.apache.org/docs/release-notes/1.8.html You can find the list of changes between 1.8.1 and earlier versions at: http://svn.apache.org/repos/asf/subversion/tags/1.8.1/CHANGES Questions, comments, and bug reports to users@subversion.apache.org. Thanks, - The Subversion Team
Subversion bug: Can't move Remote I/O Error
Hi, I am getting the following error when I am trying to commit: svn: Commit failed (details follow): svn: Can't move '/.../db/txn-protorevs/5-9.rev' to '/.../db/revs/0/6': Remote I/O error Please help. Thanks, Prateeti Mohapatra
Re: Subversion bug: Can't move Remote I/O Error
Guten Tag Prateeti Mohapatra, am Mittwoch, 24. Juli 2013 um 19:26 schrieben Sie: svn: Commit failed (details follow): svn: Can't move '/.../db/txn-protorevs/5-9.rev' to '/.../db/revs/0/6': Remote I/O error This is something you should your server/repo admins first, there surely is something wrong with permissions, disk space, disk hardware or stuff like that. Tell them and the list how you access your repo, because especially using svn+ssh one has to care about permissions on the repo. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Backup strategy sanity check
I'm planning my upgrade to SVN 1.8 to go along with it, setting up a new backup process. Here's what I'm thinking: * Monday overnight, take a full backup (svnadmin hotcopy, then compress the result for storage) * Tuesday through Sunday overnights, incremental backups (svnadmin dump --incremental, compress the result) * After completing the Monday night full backup, purge the previous week's incrementals. * After completing the Monday night full backup, run svnadmin pack * Keep the last 6 full backups on local disk (these will be kept written to the corporate backup system, so we can go back further if needed). I'm saving the packing for after the Monday full backup so that in case something goes wrong with it, I have the full backup right there that I can restore from. Will svnadmin pack have a significant impact on the incremental backup I take the following day(s)? I'm guessing not because those are dumps and not hotcopies, but want to be sure. I recognize that this isn't 100% air-tight, in that we're exposed during the workday, but based on the size of our repositories the frequency of commits, standing up another server to act as an svnsync mirror or adding the complexity of making a backup of each commit when it happens is more than I can get away with right now. Aside from that, is this a sound strategy? Have I overlooked anything?
Re: Backup strategy sanity check
On Wed, Jul 24, 2013 at 2:59 PM, Andy Levy andy.l...@gmail.com wrote: I'm planning my upgrade to SVN 1.8 to go along with it, setting up a new backup process. Here's what I'm thinking: * Monday overnight, take a full backup (svnadmin hotcopy, then compress the result for storage) * Tuesday through Sunday overnights, incremental backups (svnadmin dump --incremental, compress the result) Why not do this from a post-commit hook? That would reduce your exposure. Also note that there is a new --incremental option on svnadmin hotcopy. So the hook could even just do that. * After completing the Monday night full backup, purge the previous week's incrementals. * After completing the Monday night full backup, run svnadmin pack Running pack would probably make the idea of continuing to use hotcopy not work right. Will svnadmin pack have a significant impact on the incremental backup I take the following day(s)? I'm guessing not because those are dumps and not hotcopies, but want to be sure. I cannot see why it would impact a dump. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Backup strategy sanity check
On 7/24/2013 2:59 PM, Andy Levy wrote: I'm planning my upgrade to SVN 1.8 to go along with it, setting up a new backup process. Here's what I'm thinking: * Monday overnight, take a full backup (svnadmin hotcopy, then compress the result for storage) * Tuesday through Sunday overnights, incremental backups (svnadmin dump --incremental, compress the result) * After completing the Monday night full backup, purge the previous week's incrementals. * After completing the Monday night full backup, run svnadmin pack * Keep the last 6 full backups on local disk (these will be kept written to the corporate backup system, so we can go back further if needed). We simply do svnadmin hotcopy each night, then rdiff-backup that to another server over the network. The rdiff-backups keep 6 months of revisions to the hotcopy folders. Our /var/svn is 122GB (as is the hotcopy location), the rdiff-backup is 173GB. Using rdiff-backup means that I can go back to any point in time in the last 6 months for a particular repository (plus we have hashes/checksums of all files). For offsite purposes, we backup the rdiff-backup directory instead of the hotcopy directory. What we might do once 1.8 server is stable is switch to doing the new incremental style hotcopy on Mon-Sat evenings and do a full hotcopy on Sun. Right now, we address the time it takes to do full hotcopy of all 300+ repositories by only doing a nightly hotcopy of any repositories that have changes within the last N days (usually 7 days, and usually a only a few dozen repositories see activity each week). Doing the hotcopy to a different set of platters also helps. This is based on the assumption that svnadmin hotcopy is a preferred backup method over svnadmin dump for daily backups, because it grabs everything out of the repository directory while svnadmin dump misses things like scripts.
Re: Mixing recursive and non-recursive commits
The enhancement would be to include only parents marked for addition. Nothing special for prop changes as you don't want to commit these later if the directory was already committed (unless explicitly stated). So, I think's a rather simple request. If commit --parents is loaded then any parent directories for the given command line targets that are in an add state should be included in the targets passed on. Eric [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: Backup strategy sanity check
On Wed, Jul 24, 2013 at 2:22 PM, Thomas Harold thomas-li...@nybeta.com wrote: What we might do once 1.8 server is stable is switch to doing the new incremental style hotcopy on Mon-Sat evenings and do a full hotcopy on Sun. Right now, we address the time it takes to do full hotcopy of all 300+ repositories by only doing a nightly hotcopy of any repositories that have changes within the last N days (usually 7 days, and usually a only a few dozen repositories see activity each week). Doing the hotcopy to a different set of platters also helps. This is based on the assumption that svnadmin hotcopy is a preferred backup method over svnadmin dump for daily backups, because it grabs everything out of the repository directory while svnadmin dump misses things like scripts. Is that better than using svnsync from a remote server plus some normal file backup approach for the conf/hooks directories? -- Les Mikesell lesmikes...@gmail.com
Re: Mixing recursive and non-recursive commits
On Wed, Jul 24, 2013 at 07:32:20PM +, Braun, Eric wrote: The enhancement would be to include only parents marked for addition. Nothing special for prop changes as you don't want to commit these later if the directory was already committed (unless explicitly stated). So, I think's a rather simple request. If commit --parents is loaded then any parent directories for the given command line targets that are in an add state should be included in the targets passed on. Eric What would svn commit --parents do if the newly added parents are replacing a deleted item in the working copy? It seems svn would then have to commit a replacement instead of an addition. In which case this option cannot claim to be scoped to just additions, because a deletion needs to be committed as part of the replacement. The same questions applies to added items which are inside copies. Copies can only be committed recursively due to the way cheap copies are implemented in the repository. That would mean that not only parents of the explicit commit target would be committed, but also any other children of those parents. If the --parents option did nothing for copied and replaced items, it would probably have to error out if those occur. For example, the following would commit A and A/B: svn mkdir A svn mkdir A/B svn commit --parents A/B But the following would have to error out or commit the deletion of the original A, not just an addition: svn rm A svn mkdir A svn mkdir A/B svn commit --parents A/B And this would also error out or commit any children of C along with the child B, effectively committing C recursively, which defeats the idea of the --parents option: svn cp A C svn mkdir C/B svn commit --parents C/B So, due to the recursive nature of copies, the above would be equivalent to: svn cp A C svn mkdir C/B svn commit C I'm not sure how this behaviour can be defined in a consistent way. What about passing the right list of commit targets instead of adding a new --parents option? Note that the list can be passed via a file using the --targets option. Perhaps you could generate a file that includes the proper list of targets, and then run the commit?
Re: Backup strategy sanity check
On Wed, Jul 24, 2013 at 2:59 PM, Andy Levy andy.l...@gmail.com wrote: I'm planning my upgrade to SVN 1.8 to go along with it, setting up a new backup process. Here's what I'm thinking: * Monday overnight, take a full backup (svnadmin hotcopy, then compress the result for storage) Insufficient. You also need the Apache or svnserve or SSH configs, and the varoius commit scripts from the base repository, along with their ownership and permissions. Tarballs are good, rsync -avH is even better for imaging such loactions in a decodable format. * Tuesday through Sunday overnights, incremental backups (svnadmin dump --incremental, compress the result) * After completing the Monday night full backup, purge the previous week's incrementals. * After completing the Monday night full backup, run svnadmin pack * Keep the last 6 full backups on local disk (these will be kept written to the corporate backup system, so we can go back further if needed). I'm saving the packing for after the Monday full backup so that in case something goes wrong with it, I have the full backup right there that I can restore from. svnadmin does not do full backups. It does *database* backups, but does not mirror the rest of the configuration. Will svnadmin pack have a significant impact on the incremental backup I take the following day(s)? I'm guessing not because those are dumps and not hotcopies, but want to be sure. I recognize that this isn't 100% air-tight, in that we're exposed during the workday, but based on the size of our repositories the frequency of commits, standing up another server to act as an svnsync mirror or adding the complexity of making a backup of each commit when it happens is more than I can get away with right now. Aside from that, is this a sound strategy? Have I overlooked anything? See above.
