Re: svn 1.6 - compression svndiff format data failed
Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. On Tue, Dec 20, 2011 at 9:38 PM, phillip...@gmail.com wrote: Please forgive me but how do you install the v1.7 libraries on top of v1.6. Is it basically performing the compilation of v1.7 and installing it over the v1.6 directory location? On Tue, Dec 20, 2011 at 6:11 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: please reply to all so so replies go to the list phillip...@gmail.com wrote on Tue, Dec 20, 2011 at 18:00:07 -0500: Hi Daniel, Thanks for your response. I'm using a middleware product called webMethods. Not sure if their product support the latest stable release of subversion v1.7 but with v1.6, the product works well when doing api calls to check in/out. Well, you could try installing the 1.7 shared libraries on top of the 1.6 ones; should just work Anyways, by setting LC_ALL=C environment variable (I'm running AIX server), what exactly does that do? Strange that I don't have to set this when running v1.7. Force output to be in English if it's in some other language (via gettext library) On Tue, Dec 20, 2011 at 5:35 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: Phil wrote on Tue, Dec 20, 2011 at 17:22:52 -0500: Whenever I use svn:// protocol to checkout numerous files at one time, I get the error svn: compression svndiff failed data at some point. (You either misquote the message or mistranslate it. In the latter case, set LC_ALL=C in your environment.) However, this doesn't occure when using file:// protocol. Does anyone know how to resolve this with svn v1.6? This doesn't occur with svn v1.7 but I prefer to use v1.6 because it works or integrate well with another product. I'm curious about the latter part. What products do you have that work with 1.6 and not with 1.7? We publish stable public APIs exactly to prevent people from ending up in that state. -Phillip Daniel (I don't have any specific insight on your actual error though, sorry.) -- Regards, Phillip This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this documentto the intended recipient), you are hereby notified that any dissemination, distribution, printing or coping of this e-mail, and anyattachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof. -- Regards, Phillip This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this documentto the intended recipient), you are hereby notified that any dissemination, distribution, printing or coping of this e-mail, and anyattachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.
Re: svn 1.6 - compression svndiff format data failed
I have about 155 packages in the repository that I want to checkout. This has never worked with v1.6. The workaround is to checkout each package one at a time (svn co svn://). As you can see, that's very tedious. I assume subversion doesn't care how many packages are in my repository. I did the basic installation of svn v1.6 (tar'ing subversion-1.6.17.tar and subversion-deps-1.6.17.tar). Then I did another installation but with v1.7 to see if I ran into the same issue. I installed it on a different directory location. I was able to checkout the 155 packages successfully. On Wed, Dec 21, 2011 at 8:05 AM, Stefan Sperling s...@elego.de wrote: On Wed, Dec 21, 2011 at 07:47:16AM -0500, Phil wrote: Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. The error is coming from zlib when compressing data. Maybe svnserve is failing to compress data for transmission to the client via the svn:// protocol. If you use file:// the only possible interaction with zlib during a checkout is decompressing data. Though it might not even be trying to decompress anything at all depending on the content of the respitory you are checking out from. I would suspect that your Subversion 1.6 install has a problem with the zlib it is using. Has checkout ever worked with 1.6 and suddenly stopped working? Was zlib updated or recompiled without also recompiling its dependencies? Or are you trying to get a fresh Subversion install working? That's all I can tell you given the information you provided. Not sure what the problem really is, though.
Re: svn 1.6 - compression svndiff format data failed
Maybe I should download and get a better zlib package. Let me try and keep everyone posted. On Wed, Dec 21, 2011 at 9:14 AM, Phil cwst...@gmail.com wrote: I have about 155 packages in the repository that I want to checkout. This has never worked with v1.6. The workaround is to checkout each package one at a time (svn co svn://). As you can see, that's very tedious. I assume subversion doesn't care how many packages are in my repository. I did the basic installation of svn v1.6 (tar'ing subversion-1.6.17.tar and subversion-deps-1.6.17.tar). Then I did another installation but with v1.7 to see if I ran into the same issue. I installed it on a different directory location. I was able to checkout the 155 packages successfully. On Wed, Dec 21, 2011 at 8:05 AM, Stefan Sperling s...@elego.de wrote: On Wed, Dec 21, 2011 at 07:47:16AM -0500, Phil wrote: Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. The error is coming from zlib when compressing data. Maybe svnserve is failing to compress data for transmission to the client via the svn:// protocol. If you use file:// the only possible interaction with zlib during a checkout is decompressing data. Though it might not even be trying to decompress anything at all depending on the content of the respitory you are checking out from. I would suspect that your Subversion 1.6 install has a problem with the zlib it is using. Has checkout ever worked with 1.6 and suddenly stopped working? Was zlib updated or recompiled without also recompiling its dependencies? Or are you trying to get a fresh Subversion install working? That's all I can tell you given the information you provided. Not sure what the problem really is, though.
Re: how to repeatedly checkout sparse directories in a cron job
On Wed, Dec 21, 2011 at 13:21, Stefan Sperling wrote: On Wed, Dec 21, 2011 at 06:07:05AM -0600, Ryan Schmidt wrote: On Dec 20, 2011, at 06:08, Mojca Miklavec wrote: Is there any way to prevent deleting existing contents within the scope of command line arguments? A workaround is to use something like if [ ! -d project ]; then svn co --depth=empty $URL fi but I would be really happy if there was some command like: please checkout $URL, but no need to fetch any files yet, in particular don't fetch 'branches'; on the other hand please don't delete 'trunk' and 'tags' if already present I don't think that exists as a built-in command as such. But probably playing with the depth settings you can get what you want. I am not very familiar with these settings however so I cannot advise. svn-viewspec.py might help: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py Thank you very much for pointing out this script. I think that it will perfectly suit the need. Mojca
Problem running svnsync - Error retrieving replay REPORT (28): No space left on device
Season's greetings all! I'm using svnsync to copy our repositories for the FIRST time to a mirror site and running out of space, somewhere. From: RH ES 4, Update 5 32-bit server To: CentOS Release 5.5, 64-bit server I tried to watch the disk partitions with a df -h and the numbers never changed. Here's the significant portions of the terminal session: csvn@ala-svn % svnsync init http://ala-cvstst/svn/adimages http://ala-svn/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Copied properties for revision 0. csvn@ala-svn % csvn@ala-svn % svnsync sync http://ala-cvstst/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Transmitting file data . Committed revision 1. Copied properties for revision 1. ... snip ... Committed revision 9. Copied properties for revision 9. Transmitting file data .svnsync: Error retrieving replay REPORT (28): No space left on device csvn@ala-svn % If I try again: % svnsync sync http://ala-cvstst/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Transmitting file data .svnsync: Error retrieving replay REPORT (28): No space left on device It is a relatively large repository (2 GB), with some larger image and video files. Where are the temporary files (.svnsync ?) kept. Is the error on the source server or the destination server? Thank you, John Curley, SCM Group, Wind River
RE: Problem running svnsync - Error retrieving replay REPORT (28): No space left on device
I should have mentioned that I'm using Subversion 1.6.4 on the source side and Subversion 1.6.17 on the destination side. -Original Message- From: Curley, John [mailto:john.cur...@windriver.com] Sent: Wednesday, December 21, 2011 1:58 PM To: users@subversion.apache.org Subject: Problem running svnsync - Error retrieving replay REPORT (28): No space left on device Season's greetings all! I'm using svnsync to copy our repositories for the FIRST time to a mirror site and running out of space, somewhere. From: RH ES 4, Update 5 32-bit server To: CentOS Release 5.5, 64-bit server I tried to watch the disk partitions with a df -h and the numbers never changed. Here's the significant portions of the terminal session: csvn@ala-svn % svnsync init http://ala-cvstst/svn/adimages http://ala-svn/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Copied properties for revision 0. csvn@ala-svn % csvn@ala-svn % svnsync sync http://ala-cvstst/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Transmitting file data . Committed revision 1. Copied properties for revision 1. ... snip ... Committed revision 9. Copied properties for revision 9. Transmitting file data .svnsync: Error retrieving replay REPORT (28): No space left on device csvn@ala-svn % If I try again: % svnsync sync http://ala-cvstst/svn/adimages Authentication realm: http://ala-cvstst:80 Subversion AD Images repository Password for 'csvn': Transmitting file data .svnsync: Error retrieving replay REPORT (28): No space left on device It is a relatively large repository (2 GB), with some larger image and video files. Where are the temporary files (.svnsync ?) kept. Is the error on the source server or the destination server? Thank you, John Curley, SCM Group, Wind River
Request for thoughts on working copy enhancement request
One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following: 1) Check out 2) Make changes 3) Realize that this should be more than one commit 4) Copy directory MyCode to MyCode2 5) Revert changes I don't want to commit yet from MyCode2 6) Commit MyCode2 7) Delete MyCode2 8) Update MyCode; already committed changes are merged and no longer appears as diffs. 9) Commit remaining changes in MyCode Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows: 1) Copy the entire working copy (multiple GBs, waste of time), or 2) Do an svn info to get repo and revision, then check this out somewhere to obtain the necessary .svn folder which is then copied to MyCode. Neither of these is very elegant. I'd like to see a new svn command such as svn localize (don't keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, and possibly a svn delocalize to reintegrate it. (Although this can be accomplished less effectively by simply deleting the .svn directory and doing an update.) Is there already a way to do this? Thoughts? Randon Spackman
Re: Request for thoughts on working copy enhancement request
Randon, On Wed, Dec 21, 2011 at 3:10 PM, Randon Spackman randon.spack...@hotdocs.com wrote: One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following: ** ** **1) **Check out **2) **Make changes **3) **Realize that this should be more than one commit **4) **Copy directory “MyCode” to “MyCode2” **5) **Revert changes I don’t want to commit yet from “MyCode2” **6) **Commit “MyCode2” **7) **Delete “MyCode2” **8) **Update “MyCode”; already committed changes are merged and no longer appears as diffs. **9) **Commit remaining changes in “MyCode” ** ** Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows: **1) **Copy the entire working copy (multiple GBs, waste of time), or **2) **Do an “svn info” to get repo and revision, then check this out somewhere to obtain the necessary “.svn” folder which is then copied to “MyCode”. ** ** Neither of these is very elegant. I’d like to see a new svn command such as “svn localize” (don’t keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, and possibly a “svn delocalize” to reintegrate it. (Although this can be accomplished less effectively by simply deleting the “.svn” directory and doing an update.) ** ** Is there already a way to do this? Thoughts? This sounds like a good case to use changelists. See: http://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html for details. chris
Re: Request for thoughts on working copy enhancement request
Sounds like a feature much like git's git stash On 21 December 2011 20:10, Randon Spackman randon.spack...@hotdocs.com wrote: One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following: 1) Check out 2) Make changes 3) Realize that this should be more than one commit 4) Copy directory “MyCode” to “MyCode2” 5) Revert changes I don’t want to commit yet from “MyCode2” 6) Commit “MyCode2” 7) Delete “MyCode2” 8) Update “MyCode”; already committed changes are merged and no longer appears as diffs. 9) Commit remaining changes in “MyCode” Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows: 1) Copy the entire working copy (multiple GBs, waste of time), or 2) Do an “svn info” to get repo and revision, then check this out somewhere to obtain the necessary “.svn” folder which is then copied to “MyCode”. Neither of these is very elegant. I’d like to see a new svn command such as “svn localize” (don’t keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, and possibly a “svn delocalize” to reintegrate it. (Although this can be accomplished less effectively by simply deleting the “.svn” directory and doing an update.) Is there already a way to do this? Thoughts? Randon Spackman
RE: Request for thoughts on working copy enhancement request
Hmm... It's close, but the limitations on only assigning one per file are a bit onerous; it's very often in the same file that I'm working on that I find bugs, etc., that I want to commit separately. Randon From: Chris Shelton [mailto:cshel...@shelton-family.net] Sent: Wednesday, December 21, 2011 5:28 PM To: Randon Spackman Cc: users@subversion.apache.org Subject: Re: Request for thoughts on working copy enhancement request Randon, On Wed, Dec 21, 2011 at 3:10 PM, Randon Spackman randon.spack...@hotdocs.commailto:randon.spack...@hotdocs.com wrote: One of my common use cases for subversion is to want to split my changes into two separate commits. In the past, I would do the following: 1) Check out 2) Make changes 3) Realize that this should be more than one commit 4) Copy directory MyCode to MyCode2 5) Revert changes I don't want to commit yet from MyCode2 6) Commit MyCode2 7) Delete MyCode2 8) Update MyCode; already committed changes are merged and no longer appears as diffs. 9) Commit remaining changes in MyCode Unfortunately, this use case is defeated by the 1.7 changes to a single .svn dir. My current workarounds are as follows: 1) Copy the entire working copy (multiple GBs, waste of time), or 2) Do an svn info to get repo and revision, then check this out somewhere to obtain the necessary .svn folder which is then copied to MyCode. Neither of these is very elegant. I'd like to see a new svn command such as svn localize (don't keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, and possibly a svn delocalize to reintegrate it. (Although this can be accomplished less effectively by simply deleting the .svn directory and doing an update.) Is there already a way to do this? Thoughts? This sounds like a good case to use changelists. See: http://svnbook.red-bean.com/nightly/en/svn.advanced.changelists.html for details. chris
Re: svn 1.6 - compression svndiff format data failed
Well, it turns out that the other application does not support svn v1.7 but only v1.6. Too bad I still cannot get v1.6 to perform massive checkout using the svn co svn://... syntax. I guess I would have to write a unix shell script to help speed up my manual process. What I'm doing is first perform svn co svn://... -depth immediate. Then svn update -depth infinity on each of the package folder (total 155). Please let me know if anyone is able to figure this out and get it working. Thanks in advance. On Wed, Dec 21, 2011 at 6:32 AM, Phil cwst...@gmail.com wrote: Maybe I should download and get a better zlib package. Let me try and keep everyone posted. On Wed, Dec 21, 2011 at 9:14 AM, Phil cwst...@gmail.com wrote: I have about 155 packages in the repository that I want to checkout. This has never worked with v1.6. The workaround is to checkout each package one at a time (svn co svn://). As you can see, that's very tedious. I assume subversion doesn't care how many packages are in my repository. I did the basic installation of svn v1.6 (tar'ing subversion-1.6.17.tar and subversion-deps-1.6.17.tar). Then I did another installation but with v1.7 to see if I ran into the same issue. I installed it on a different directory location. I was able to checkout the 155 packages successfully. On Wed, Dec 21, 2011 at 8:05 AM, Stefan Sperling s...@elego.de wrote: On Wed, Dec 21, 2011 at 07:47:16AM -0500, Phil wrote: Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. The error is coming from zlib when compressing data. Maybe svnserve is failing to compress data for transmission to the client via the svn:// protocol. If you use file:// the only possible interaction with zlib during a checkout is decompressing data. Though it might not even be trying to decompress anything at all depending on the content of the respitory you are checking out from. I would suspect that your Subversion 1.6 install has a problem with the zlib it is using. Has checkout ever worked with 1.6 and suddenly stopped working? Was zlib updated or recompiled without also recompiling its dependencies? Or are you trying to get a fresh Subversion install working? That's all I can tell you given the information you provided. Not sure what the problem really is, though.
Re: svn 1.6 - compression svndiff format data failed
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py Phil wrote on Wed, Dec 21, 2011 at 16:44:36 -0800: Well, it turns out that the other application does not support svn v1.7 but only v1.6. Too bad I still cannot get v1.6 to perform massive checkout using the svn co svn://... syntax. I guess I would have to write a unix shell script to help speed up my manual process. What I'm doing is first perform svn co svn://... -depth immediate. Then svn update -depth infinity on each of the package folder (total 155). Please let me know if anyone is able to figure this out and get it working. Thanks in advance. On Wed, Dec 21, 2011 at 6:32 AM, Phil cwst...@gmail.com wrote: Maybe I should download and get a better zlib package. Let me try and keep everyone posted. On Wed, Dec 21, 2011 at 9:14 AM, Phil cwst...@gmail.com wrote: I have about 155 packages in the repository that I want to checkout. This has never worked with v1.6. The workaround is to checkout each package one at a time (svn co svn://). As you can see, that's very tedious. I assume subversion doesn't care how many packages are in my repository. I did the basic installation of svn v1.6 (tar'ing subversion-1.6.17.tar and subversion-deps-1.6.17.tar). Then I did another installation but with v1.7 to see if I ran into the same issue. I installed it on a different directory location. I was able to checkout the 155 packages successfully. On Wed, Dec 21, 2011 at 8:05 AM, Stefan Sperling s...@elego.de wrote: On Wed, Dec 21, 2011 at 07:47:16AM -0500, Phil wrote: Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. The error is coming from zlib when compressing data. Maybe svnserve is failing to compress data for transmission to the client via the svn:// protocol. If you use file:// the only possible interaction with zlib during a checkout is decompressing data. Though it might not even be trying to decompress anything at all depending on the content of the respitory you are checking out from. I would suspect that your Subversion 1.6 install has a problem with the zlib it is using. Has checkout ever worked with 1.6 and suddenly stopped working? Was zlib updated or recompiled without also recompiling its dependencies? Or are you trying to get a fresh Subversion install working? That's all I can tell you given the information you provided. Not sure what the problem really is, though.
Re: svn 1.6 - compression svndiff format data failed
Daniel, Please forgive me but I'm not familiar with *.py On Wed, Dec 21, 2011 at 7:52 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-viewspec.py Phil wrote on Wed, Dec 21, 2011 at 16:44:36 -0800: Well, it turns out that the other application does not support svn v1.7 but only v1.6. Too bad I still cannot get v1.6 to perform massive checkout using the svn co svn://... syntax. I guess I would have to write a unix shell script to help speed up my manual process. What I'm doing is first perform svn co svn://... -depth immediate. Then svn update -depth infinity on each of the package folder (total 155). Please let me know if anyone is able to figure this out and get it working. Thanks in advance. On Wed, Dec 21, 2011 at 6:32 AM, Phil cwst...@gmail.com wrote: Maybe I should download and get a better zlib package. Let me try and keep everyone posted. On Wed, Dec 21, 2011 at 9:14 AM, Phil cwst...@gmail.com wrote: I have about 155 packages in the repository that I want to checkout. This has never worked with v1.6. The workaround is to checkout each package one at a time (svn co svn://). As you can see, that's very tedious. I assume subversion doesn't care how many packages are in my repository. I did the basic installation of svn v1.6 (tar'ing subversion-1.6.17.tar and subversion-deps-1.6.17.tar). Then I did another installation but with v1.7 to see if I ran into the same issue. I installed it on a different directory location. I was able to checkout the 155 packages successfully. On Wed, Dec 21, 2011 at 8:05 AM, Stefan Sperling s...@elego.de wrote: On Wed, Dec 21, 2011 at 07:47:16AM -0500, Phil wrote: Setting LC_ALL=C does not work either. Wonder why it works for v1.7 but not for v1.6. Again, I'm getting svn: Compression of svndiff data failed when executing svn co svn://path/to/repo/prj working_directory. But if I do a svn co file:/// then it's okay for v1.6. The error is coming from zlib when compressing data. Maybe svnserve is failing to compress data for transmission to the client via the svn:// protocol. If you use file:// the only possible interaction with zlib during a checkout is decompressing data. Though it might not even be trying to decompress anything at all depending on the content of the respitory you are checking out from. I would suspect that your Subversion 1.6 install has a problem with the zlib it is using. Has checkout ever worked with 1.6 and suddenly stopped working? Was zlib updated or recompiled without also recompiling its dependencies? Or are you trying to get a fresh Subversion install working? That's all I can tell you given the information you provided. Not sure what the problem really is, though.
Re: Request for thoughts on working copy enhancement request
On 12/21/2011 4:31 PM, Randon Spackman wrote: Hmm... It's close, but the limitations on only assigning one per file are a bit onerous; it's very often in the same file that I'm working on that I find bugs, etc., that I want to commit separately. Randon Normally I have one main sandbox and one quick updates sandbox. The latter doesn't get used very often - only when I need to fix something quickly while the code in the main sandbox is in an unstable state. Updating this backup sandbox takes much less time than a full update, and my machine is not so small that a few gigabytes of duplicated storage would fill it. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: svn 1.6 - compression svndiff format data failed
On Dec 21, 2011, at 19:01, Phil wrote: Please forgive me but I'm not familiar with *.py It's a Python script. http://en.wikipedia.org/wiki/Python_%28programming_language%29
Re: Request for thoughts on working copy enhancement request
On Dec 21, 2011, at 14:10, Randon Spackman wrote: I’d like to see a new svn command such as “svn localize” (don’t keep my terminology if it sucks) that would make the directory you specify its own independent working copy that can be copied and manipulated individually, This function has been called detach here before and is implemented in this script: http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/detach.py Here's the issue requesting a proper svn command for this: http://subversion.tigris.org/issues/show_bug.cgi?id=2884 and possibly a “svn delocalize” to reintegrate it. (Although this can be accomplished less effectively by simply deleting the “.svn” directory and doing an update.) I'm not aware of any work to make this possible.
