Re: Breaking up a monolothic repository
Guten Tag Trent W. Buck, am Montag, 9. September 2013 um 03:13 schrieben Sie: What else can I do? Tell us about the size of your repo, it's format version and primary data types versioned, as you always can simply clone the entire repo into one for each project needed and delete and move unneeded contents per new project repo with a Subversion client. The current format of the repo and it's primary data types are interesting because if it's pretty old, current repo versions may provide a significantly reduced disk space per repo, making the overhead of duplicating the original one acceptable. 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
RE: SilkSVN client crashing
Hi again, I'm not really familiar with VS (nowadays :)), but are you saying that if I place the pdb:s in the same dir as the svn.exe (C:\Program Files\SlikSvn\bin on my machine), the crash log will contain better info for you guys? If so I can totally do that. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 7 september 2013 13:18 To: Bjarne Grönnevik; users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi, Ivan Zhakov and I checked the minidump but the only thing we could find using the dump is that the application fails when writing an error message. So 'some error' occurred while producing the log, but we don't know which and somehow the handling corrupted the error state. We are looking for a way to get more information. As part of this investigation we started publishing the debug symbols for the SlikSvn binaries on http://sliksvn.com/pub/symbols/. If you know your way around Visual Studio and/or another debugger you might be able to help us. It might also help to just copy the right .pdb files next to the .exe/.dll files as that improves the debug output in the .log file. Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: vrijdag 6 september 2013 16:54 To: Bert Huijben; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi again Bert, I updated to 1.8.3 and the error is still present. Some extended info about this: - I can't reproduce the crash by running the command on the regular windows command-line. - It happens quite reliably when I run the same command from the python script. - The commands seem to be failing when the resulting log is extensive(like been in development since 2008 with regular updates). - I seem to be able to avoid the error using the -l flag(in this particular case this is fine as I don't want anything more than a few of the last entries anyway) See attachment of the python script, its output and the crash log and dump. I hope that helps. Cheers /Bjarne From: Bjarne Grönnevik Sent: den 6 september 2013 16:09 To: 'Bert Huijben'; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bert Sure, I'll attempt to provoke it with that version. Get back to you soon with the results. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 5 september 2013 10:00 To: Bjarne Grönnevik; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bjarne, Can you run the svn log https://svn.netentertainment.com/cm_games_ng/igames/blacklagoon/blacklagoon-common/trunk command. With SlikSvn 1.8.3 (which is available on http://sliksvn.com/en/download) and if you can reproduce the result send me the log and dump files? Thanks, Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: donderdag 5 september 2013 09:38 To: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: SilkSVN client crashing Hi I'm scripting svn via a Python Script and as you can see in the run-log.txt, svn seems to fail at random occasions(see crash logs). Or at least for reasons unknown to me. And as the error message suggest helping out by mailing here, I did. Svn version is: svn, version 1.8.1-SlikSvn-1.8.1-X64 (SlikSvn/1.8.1) X64, compiled Aug 26 2013, 16:52:34 on x86_64/x86-microsoft-windows6.1.7601 Os is: Windows 7 Enterprice, 64-bit, Service Pack 1 /Bjarne Bjarne Grönnevik Client Developer Net Entertainment NE AB, Luntmakargatan 18, SE-111 37, Stockholm, SE T: +46 709 124 588, M: +46 709 124 588, F: +46 8 578 545 10 bjarne.gronne...@netent.commailto:bjarne.gronne...@netent.com www.netent.comhttp://www.netent.com Better Games This email and the information it contains are confidential and may be legally privileged and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify me immediately. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. You should not copy it for any purpose, or disclose its contents to any other person. Internet communications are not secure and, therefore, Net Entertainment does not accept legal responsibility for the contents of this message as it has been transmitted over a public network. If you suspect the message may have been intercepted or amended please call me. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Thank you.
svn: E120104: ra_serf: An error occurred during decompression
Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. The following section in the STATUS file looks highly relevant: * ^/subversion/branches/1.8.x-serf-1.3+-windows Allow compiling against serf 1.3 and later on Windows Justification: Serf 1.3 brings a lot of fixes that we need for 1.8.x stability. Notes: The dependency handling on Windows was updated for 1.9+, so this needs a specific backport patch (r1517123) Votes: +1: rhuijben, brane Cheers, James
RE: E120104: ra_serf: An error occurred during decompression
The current TortoiseSVN is already compiled against serf 1.3 as far as I can tell. (TortoiseSVN uses its own custom build system and this patch just affects the build system) Bert From: James French [mailto:james.fre...@naturalmotion.com] Sent: maandag 9 september 2013 13:15 To: users@subversion.apache.org Subject: svn: E120104: ra_serf: An error occurred during decompression Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. The following section in the STATUS file looks highly relevant: * ^/subversion/branches/1.8.x-serf-1.3+-windows Allow compiling against serf 1.3 and later on Windows Justification: Serf 1.3 brings a lot of fixes that we need for 1.8.x stability. Notes: The dependency handling on Windows was updated for 1.9+, so this needs a specific backport patch (r1517123) Votes: +1: rhuijben, brane Cheers, James
RE: E120104: ra_serf: An error occurred during decompression
Hmm, actually I made a mistake. The merge was done through our own gui tool that actually uses svn 1.8.1 command line. Looks like there are a few serf fixes in 1.8.3 but the status entry I found looks very suspicious. From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 09 September 2013 12:51 To: James French; users@subversion.apache.org Subject: RE: E120104: ra_serf: An error occurred during decompression The current TortoiseSVN is already compiled against serf 1.3 as far as I can tell. (TortoiseSVN uses its own custom build system and this patch just affects the build system) Bert From: James French [mailto:james.fre...@naturalmotion.com] Sent: maandag 9 september 2013 13:15 To: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: svn: E120104: ra_serf: An error occurred during decompression Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. The following section in the STATUS file looks highly relevant: * ^/subversion/branches/1.8.x-serf-1.3+-windows Allow compiling against serf 1.3 and later on Windows Justification: Serf 1.3 brings a lot of fixes that we need for 1.8.x stability. Notes: The dependency handling on Windows was updated for 1.9+, so this needs a specific backport patch (r1517123) Votes: +1: rhuijben, brane Cheers, James
Re: Breaking up a monolothic repository
On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck trentb...@gmail.com wrote: I'm stuck. Since it's no fun to have tens of thousands of empty revs in each project repo, my current approach is to leave existing projects in the monolithic repo, and new projects get separate repos. Why do you think an empty rev will bother anyone any more in a per-project rev that having the rev number jump from a commit to an unrelated project does in the combined repo?It shouldn't be a problem in either case. Rev numbers for any particular use don't need to be sequential, you just need to know what they are. -- Les Mikesell lesmikes...@gmail.com
Re: svn: E120104: ra_serf: An error occurred during decompression
On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com wrote: Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. This looks very much like the error I ran into during testing of 1.8.3, and which spawned the following discussion on the dev-list: http://svn.haxx.se/dev/archive-2013-08/0386.shtml (it was with an 'svn export' over plain http of a tag of the subversion project itself, but the problem might be the same) Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in the serf http-library (with me trying various patches and reproducing the issue), but so far without success. It's good to know that now I'm not the only one seeing this problem. Can you report your OS version please? Can you reproduce it with Antivirus disabled? Also: I couldn't reproduce the issue with compression disabled, by adding the option --config-option servers:global:http-compression=off to the command line (or configure that setting in your 'servers' configuration file). That might be a workaround for you (though it will probably make things go a lot slower). -- Johan
RE: svn: E120104: ra_serf: An error occurred during decompression
-Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: 09 September 2013 13:36 To: James French Cc: users@subversion.apache.org Subject: Re: svn: E120104: ra_serf: An error occurred during decompression On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com wrote: Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. This looks very much like the error I ran into during testing of 1.8.3, and which spawned the following discussion on the dev-list: http://svn.haxx.se/dev/archive-2013-08/0386.shtml (it was with an 'svn export' over plain http of a tag of the subversion project itself, but the problem might be the same) Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in the serf http-library (with me trying various patches and reproducing the issue), but so far without success. It's good to know that now I'm not the only one seeing this problem. Likewise :-) Can you report your OS version please? Windows7 x64 Can you reproduce it with Antivirus disabled? I'm first trying with 1.8.3, then I'll try without antivirus/compression. Takes a long time as it's a massive checkout. Also: I couldn't reproduce the issue with compression disabled, by adding the option --config-option servers:global:http-compression=off to the command line (or configure that setting in your 'servers' configuration file). That might be a workaround for you (though it will probably make things go a lot slower). -- Johan
RE: SilkSVN client crashing
Maybe unrelated to your problem, but worth checking up anyway: We had lots of problems with SlikSVN until we discovered that some users had selected that SVN client because it offered a user interface in their native language, including translations of those error messages parsed by SVN. Once they switched to the English language version, everything worked fine. keal From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: 9. september 2013 10:57 To: Bert Huijben; users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi there, I added the pdb:s to the dir below, an here are 2 crash logs/dumps. /Bjarne From: Bjarne Grönnevik Sent: den 9 september 2013 09:25 To: 'Bert Huijben'; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi again, I'm not really familiar with VS (nowadays :)), but are you saying that if I place the pdb:s in the same dir as the svn.exe (C:\Program Files\SlikSvn\bin on my machine), the crash log will contain better info for you guys? If so I can totally do that. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 7 september 2013 13:18 To: Bjarne Grönnevik; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi, Ivan Zhakov and I checked the minidump but the only thing we could find using the dump is that the application fails when writing an error message. So 'some error' occurred while producing the log, but we don't know which and somehow the handling corrupted the error state. We are looking for a way to get more information. As part of this investigation we started publishing the debug symbols for the SlikSvn binaries on http://sliksvn.com/pub/symbols/. If you know your way around Visual Studio and/or another debugger you might be able to help us. It might also help to just copy the right .pdb files next to the .exe/.dll files as that improves the debug output in the .log file. Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: vrijdag 6 september 2013 16:54 To: Bert Huijben; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi again Bert, I updated to 1.8.3 and the error is still present. Some extended info about this: - I can't reproduce the crash by running the command on the regular windows command-line. - It happens quite reliably when I run the same command from the python script. - The commands seem to be failing when the resulting log is extensive(like been in development since 2008 with regular updates). - I seem to be able to avoid the error using the -l flag(in this particular case this is fine as I don't want anything more than a few of the last entries anyway) See attachment of the python script, its output and the crash log and dump. I hope that helps. Cheers /Bjarne From: Bjarne Grönnevik Sent: den 6 september 2013 16:09 To: 'Bert Huijben'; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bert Sure, I'll attempt to provoke it with that version. Get back to you soon with the results. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 5 september 2013 10:00 To: Bjarne Grönnevik; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bjarne, Can you run the svn log https://svn.netentertainment.com/cm_games_ng/igames/blacklagoon/blacklagoon-common/trunk command. With SlikSvn 1.8.3 (which is available on http://sliksvn.com/en/download) and if you can reproduce the result send me the log and dump files? Thanks, Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: donderdag 5 september 2013 09:38 To: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: SilkSVN client crashing Hi I'm scripting svn via a Python Script and as you can see in the run-log.txt, svn seems to fail at random occasions(see crash logs). Or at least for reasons unknown to me. And as the error message suggest helping out by mailing here, I did. Svn version is: svn, version 1.8.1-SlikSvn-1.8.1-X64 (SlikSvn/1.8.1) X64, compiled Aug 26 2013, 16:52:34 on x86_64/x86-microsoft-windows6.1.7601 Os is: Windows 7 Enterprice, 64-bit, Service Pack 1 /Bjarne Bjarne Grönnevik Client Developer Net Entertainment NE AB, Luntmakargatan 18, SE-111 37, Stockholm, SE T: +46 709 124 588, M: +46 709 124 588, F: +46 8 578 545 10 bjarne.gronne...@netent.commailto:bjarne.gronne...@netent.com www.netent.comhttp://www.netent.com Better Games This email and the information it contains are confidential and may be legally privileged and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify me immediately. Please note that any views or
RE: svn: E120104: ra_serf: An error occurred during decompression
I tried it again with the 1.8.3 command line and the merge went through... -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: 09 September 2013 13:36 To: James French Cc: users@subversion.apache.org Subject: Re: svn: E120104: ra_serf: An error occurred during decompression On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com wrote: Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. This looks very much like the error I ran into during testing of 1.8.3, and which spawned the following discussion on the dev-list: http://svn.haxx.se/dev/archive-2013-08/0386.shtml (it was with an 'svn export' over plain http of a tag of the subversion project itself, but the problem might be the same) Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in the serf http-library (with me trying various patches and reproducing the issue), but so far without success. It's good to know that now I'm not the only one seeing this problem. Can you report your OS version please? Can you reproduce it with Antivirus disabled? Also: I couldn't reproduce the issue with compression disabled, by adding the option --config-option servers:global:http-compression=off to the command line (or configure that setting in your 'servers' configuration file). That might be a workaround for you (though it will probably make things go a lot slower). -- Johan
RE: Breaking up a monolothic repository
I can see Trent's view point that people are weird and get freaked out by the unexpected (where they might expect the revision numbers to be relatively low). I guess what we should be providing him are points like you do make to help him sell why this isn't an issue to the end users. Like Les says, if someone performs a large batch of commits to a particular branch then the trunk revision numbers are going to leap forward (unexpectedly). So what to sell those folks concerned about it is that they're experiencing this already. -- David Grierson - SDLC Tools Specialist Sky Broadcasting - Customer Business Systems - SDLC Tools Tel: +44 1506 325100 / Email: david.grier...@bskyb.com / Chatter: CBS SDLC Tools Watermark Building, Alba Campus, Livingston, EH54 7HH -Original Message- From: Les Mikesell [mailto:lesmikes...@gmail.com] Sent: 09 September 2013 13:32 To: Trent W. Buck Cc: Subversion Subject: Re: Breaking up a monolothic repository On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck trentb...@gmail.com wrote: I'm stuck. Since it's no fun to have tens of thousands of empty revs in each project repo, my current approach is to leave existing projects in the monolithic repo, and new projects get separate repos. Why do you think an empty rev will bother anyone any more in a per-project rev that having the rev number jump from a commit to an unrelated project does in the combined repo?It shouldn't be a problem in either case. Rev numbers for any particular use don't need to be sequential, you just need to know what they are. -- Les Mikesell lesmikes...@gmail.com Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and Sky International AG and are used under licence. British Sky Broadcasting Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of British Sky Broadcasting Group plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.
RE: SilkSVN client crashing
Well, I'm running everything I know about in English so I guess that should not be a problem, right? /B From: Albertsen, Ketil [mailto:ketil.albert...@nordicsemi.no] Sent: den 9 september 2013 14:57 To: Bjarne Grönnevik; Bert Huijben; users@subversion.apache.org Subject: RE: SilkSVN client crashing Maybe unrelated to your problem, but worth checking up anyway: We had lots of problems with SlikSVN until we discovered that some users had selected that SVN client because it offered a user interface in their native language, including translations of those error messages parsed by SVN. Once they switched to the English language version, everything worked fine. keal From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: 9. september 2013 10:57 To: Bert Huijben; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi there, I added the pdb:s to the dir below, an here are 2 crash logs/dumps. /Bjarne From: Bjarne Grönnevik Sent: den 9 september 2013 09:25 To: 'Bert Huijben'; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi again, I'm not really familiar with VS (nowadays :)), but are you saying that if I place the pdb:s in the same dir as the svn.exe (C:\Program Files\SlikSvn\bin on my machine), the crash log will contain better info for you guys? If so I can totally do that. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 7 september 2013 13:18 To: Bjarne Grönnevik; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi, Ivan Zhakov and I checked the minidump but the only thing we could find using the dump is that the application fails when writing an error message. So 'some error' occurred while producing the log, but we don't know which and somehow the handling corrupted the error state. We are looking for a way to get more information. As part of this investigation we started publishing the debug symbols for the SlikSvn binaries on http://sliksvn.com/pub/symbols/. If you know your way around Visual Studio and/or another debugger you might be able to help us. It might also help to just copy the right .pdb files next to the .exe/.dll files as that improves the debug output in the .log file. Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: vrijdag 6 september 2013 16:54 To: Bert Huijben; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi again Bert, I updated to 1.8.3 and the error is still present. Some extended info about this: - I can't reproduce the crash by running the command on the regular windows command-line. - It happens quite reliably when I run the same command from the python script. - The commands seem to be failing when the resulting log is extensive(like been in development since 2008 with regular updates). - I seem to be able to avoid the error using the -l flag(in this particular case this is fine as I don't want anything more than a few of the last entries anyway) See attachment of the python script, its output and the crash log and dump. I hope that helps. Cheers /Bjarne From: Bjarne Grönnevik Sent: den 6 september 2013 16:09 To: 'Bert Huijben'; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bert Sure, I'll attempt to provoke it with that version. Get back to you soon with the results. /Bjarne From: Bert Huijben [mailto:b...@qqmail.nl] Sent: den 5 september 2013 10:00 To: Bjarne Grönnevik; users@subversion.apache.orgmailto:users@subversion.apache.org Subject: RE: SilkSVN client crashing Hi Bjarne, Can you run the svn log https://svn.netentertainment.com/cm_games_ng/igames/blacklagoon/blacklagoon-common/trunk command. With SlikSvn 1.8.3 (which is available on http://sliksvn.com/en/download) and if you can reproduce the result send me the log and dump files? Thanks, Bert From: Bjarne Grönnevik [mailto:bjarne.gronne...@netent.com] Sent: donderdag 5 september 2013 09:38 To: users@subversion.apache.orgmailto:users@subversion.apache.org Subject: SilkSVN client crashing Hi I'm scripting svn via a Python Script and as you can see in the run-log.txt, svn seems to fail at random occasions(see crash logs). Or at least for reasons unknown to me. And as the error message suggest helping out by mailing here, I did. Svn version is: svn, version 1.8.1-SlikSvn-1.8.1-X64 (SlikSvn/1.8.1) X64, compiled Aug 26 2013, 16:52:34 on x86_64/x86-microsoft-windows6.1.7601 Os is: Windows 7 Enterprice, 64-bit, Service Pack 1 /Bjarne Bjarne Grönnevik Client Developer Net Entertainment NE AB, Luntmakargatan 18, SE-111 37, Stockholm, SE T: +46 709 124 588, M: +46 709 124 588, F: +46 8 578 545 10
RE: svn: E120104: ra_serf: An error occurred during decompression
I guess the final thing to add is that I was using 1.8.1 collabnet x64 and 1.7.3 wandisco 1.8.3 (serf 1.3.1). The 1.8.1 version doesn't report which version of serf is being used but their changelog indicates it might be 1.2.1: Version 1.8.1 https://dist.apache.org/repos/dist/dev/subversion/ Changes to included binaries: * Subversion upgraded to 1.8.1. * APR 1.4.8. * APR-Util 1.5.2. * Httpd 2.2.25. * Sqlite3 3.7.17. Version 1.8.0-2 https://dist.apache.org/repos/dist/dev/subversion/ Changes to included binaries: * Subversion upgraded to 1.8.0. * OpenSSL 1.0.1e. * Serf 1.2.1. * Neon removed. -Original Message- From: James French [mailto:james.fre...@naturalmotion.com] Sent: 09 September 2013 14:03 To: Johan Corveleyn Cc: users@subversion.apache.org Subject: RE: svn: E120104: ra_serf: An error occurred during decompression I tried it again with the 1.8.3 command line and the merge went through... -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: 09 September 2013 13:36 To: James French Cc: users@subversion.apache.org Subject: Re: svn: E120104: ra_serf: An error occurred during decompression On Mon, Sep 9, 2013 at 1:14 PM, James French james.fre...@naturalmotion.com wrote: Hi list, I hit this when doing a reintegrate merge with svn 1.8.3 (tortoisesvn 1.8.2). I repeated the operation with svn 1.7.8 and it did not occur. This looks very much like the error I ran into during testing of 1.8.3, and which spawned the following discussion on the dev-list: http://svn.haxx.se/dev/archive-2013-08/0386.shtml (it was with an 'svn export' over plain http of a tag of the subversion project itself, but the problem might be the same) Lieven Govaerts and Ivan Zhakov have been trying to find the exact problem in the serf http-library (with me trying various patches and reproducing the issue), but so far without success. It's good to know that now I'm not the only one seeing this problem. Can you report your OS version please? Can you reproduce it with Antivirus disabled? Also: I couldn't reproduce the issue with compression disabled, by adding the option --config-option servers:global:http-compression=off to the command line (or configure that setting in your 'servers' configuration file). That might be a workaround for you (though it will probably make things go a lot slower). -- Johan
Re: svn: E120104: ra_serf: An error occurred during decompression
On Mon, Sep 9, 2013 at 3:02 PM, James French james.fre...@naturalmotion.com wrote: I tried it again with the 1.8.3 command line and the merge went through... Okay, I'm happy for you that it worked :-). However, I'm not convinced the error is gone. In my case it would also only fail intermittently. I couldn't reproduce it all the time (it happened perhaps 1 in 4 or 5 attempts). If you would run into the error again, please let us know ... (in my case, we were able to reduce the reproduction recipe, by only doing an 'svn export --depth=immediates http://svn.apache.org/repos/asf/subversion/tags/1.8.3/' - within a couple of attempts of that export I would run into the issue (I can reproduce it with both serf 1.2.1 and 1.3.1). Maybe you can also try exactly this export a couple of times?) -- Johan
RE: svn: E120104: ra_serf: An error occurred during decompression
-Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: 09 September 2013 14:13 To: James French Cc: users@subversion.apache.org Subject: Re: svn: E120104: ra_serf: An error occurred during decompression On Mon, Sep 9, 2013 at 3:02 PM, James French james.fre...@naturalmotion.com wrote: I tried it again with the 1.8.3 command line and the merge went through... Okay, I'm happy for you that it worked :-). However, I'm not convinced the error is gone. In my case it would also only fail intermittently. I couldn't reproduce it all the time (it happened perhaps 1 in 4 or 5 attempts). If you would run into the error again, please let us know ... (in my case, we were able to reduce the reproduction recipe, by only doing an 'svn export --depth=immediates http://svn.apache.org/repos/asf/subversion/tags/1.8.3/' - within a couple of attempts of that export I would run into the issue (I can reproduce it with both serf 1.2.1 and 1.3.1). Maybe you can also try exactly this export a couple of times?) Tried it with 1.8.3 wandisco about 20 times and it never failed. Tried it with 1.8.1 collabnet and it failed first time. Is the version of serf used dependent on the distro then, and not a core svn thing? -- Johan
Reverse merge with 1.8.3 yielded tree conflicts
Hi, I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts when a sync up merge was reverted. I ran the merge again with 1.8.3 to confirm the issue and again using 1.7.8 command line (which worked). See the status reports below (a bit hacked manually to remove some sensitive stuff but hopefully there's enough to get an idea). Looks like a regression. 1.8.3: D Common D Common\TBCommsNetworkManagement.cpp D Common\TBCommsNetworkManagement.h D Common\TBCommsSimpleDataManager.h D Common\TBDebugDraw.cpp D Common\TBDebugDraw.h D Common\TBUtilities.cpp D Common\TBUtilities.h D ProjectData\Scenes\ResponsiveCharacter.mcn D ProjectData\Scenes\TestBoneLocking.mcn A +ProjectData\win32 C SceneInteraction local dir edit, incoming dir delete upon merge A +TBCommsNetworkManagement.cpp A +TBCommsNetworkManagement.h A +TBCommsSimpleDataManager.h A +TBDebugDraw.cpp A +TBDebugDraw.h A +TBGameCharacter.cpp A +TBGameCharacter.h A +TBUtilities.cpp A +TBUtilities.h C TestAnimationOnly local dir edit, incoming dir delete upon merge A +TestAnimationOnly.cpp A +TestAnimationOnly.h C TestBareBones local dir edit, incoming dir delete upon merge A +TestBareBones.cpp A +TestBareBones.h C TestBoneLocking local dir edit, incoming dir delete upon merge C TestInverseNetworkControl local dir edit, incoming dir delete upon merge A +TestInverseNetworkControl.cpp A +TestInverseNetworkControl.h C TestVaulting local dir edit, incoming dir delete upon merge A +TestVaulting.cpp A +TestVaulting.h M gameIntegration_WIN32.vcproj M gameIntegration_WIN32.vcxproj M gameIntegration_WIN32.vcxproj.filters M gameIntegration_WIN32.vs2008.sln M gameIntegration_WIN32.vs2010.sln M gameIntegration_X360.vcxproj M gameIntegration_X360.vcxproj.filters M gameIntegration_X360.vs2010.sln A +main.cpp Summary of conflicts: Tree conflicts: 11 1.7.8 D Common D Common\TBCommsNetworkManagement.cpp D Common\TBCommsNetworkManagement.h D Common\TBCommsSimpleDataManager.h D Common\TBDebugDraw.cpp D Common\TBDebugDraw.h D Common\TBUtilities.cpp D Common\TBUtilities.h D ProjectData\Scenes\ResponsiveCharacter.mcn D ProjectData\Scenes\TestBoneLocking.mcn A +ProjectData\win32 D SceneInteraction D SceneInteraction\SceneInteraction.cpp D SceneInteraction\SceneInteraction.h D SceneInteraction\SceneInteraction_WIN32.vcproj D SceneInteraction\SceneInteraction_WIN32.vcxproj D SceneInteraction\SceneInteraction_WIN32.vcxproj.filters D SceneInteraction\SceneInteraction_WIN32.vs2008.bat D SceneInteraction\SceneInteraction_WIN32.vs2008.sln D SceneInteraction\SceneInteraction_WIN32.vs2010.bat D SceneInteraction\SceneInteraction_WIN32.vs2010.sln D SceneInteraction\SceneInteraction_X360.vcxproj D SceneInteraction\SceneInteraction_X360.vcxproj.filters D SceneInteraction\SceneInteraction_X360.vs2010.bat D SceneInteraction\SceneInteraction_X360.vs2010.sln D SceneInteraction\TBXInput.cpp D SceneInteraction\TBXInput.h D SceneInteraction\main.cpp A +TBCommsNetworkManagement.cpp A +TBCommsNetworkManagement.h A +TBCommsSimpleDataManager.h A +TBDebugDraw.cpp A +TBDebugDraw.h A +TBGameCharacter.cpp A +TBGameCharacter.h A +TBUtilities.cpp A +TBUtilities.h D TestAnimationOnly D TestAnimationOnly\TestAnimationOnly.cpp D TestAnimationOnly\TestAnimationOnly.h D TestAnimationOnly\TestAnimationOnly_WIN32.vcproj D TestAnimationOnly\TestAnimationOnly_WIN32.vcxproj D TestAnimationOnly\TestAnimationOnly_WIN32.vcxproj.filters D TestAnimationOnly\TestAnimationOnly_WIN32.vs2008.bat D TestAnimationOnly\TestAnimationOnly_WIN32.vs2008.sln D TestAnimationOnly\TestAnimationOnly_WIN32.vs2010.bat D TestAnimationOnly\TestAnimationOnly_WIN32.vs2010.sln D TestAnimationOnly\TestAnimationOnly_X360.vcxproj D TestAnimationOnly\TestAnimationOnly_X360.vcxproj.filters D TestAnimationOnly\TestAnimationOnly_X360.vs2010.bat D TestAnimationOnly\TestAnimationOnly_X360.vs2010.sln D TestAnimationOnly\main.cpp A +TestAnimationOnly.cpp A +TestAnimationOnly.h D TestBareBones D TestBareBones\TestBareBones.cpp D TestBareBones\TestBareBones.h D TestBareBones\TestBareBones_WIN32.vcproj D TestBareBones\TestBareBones_WIN32.vcxproj D TestBareBones\TestBareBones_WIN32.vcxproj.filters D TestBareBones\TestBareBones_WIN32.vs2008.bat D TestBareBones\TestBareBones_WIN32.vs2008.sln D TestBareBones\TestBareBones_WIN32.vs2010.bat D TestBareBones\TestBareBones_WIN32.vs2010.sln D
Re: svn: E120104: ra_serf: An error occurred during decompression
On Mon, Sep 9, 2013 at 9:20 AM, James French james.fre...@naturalmotion.com wrote: -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: 09 September 2013 14:13 To: James French Cc: users@subversion.apache.org Subject: Re: svn: E120104: ra_serf: An error occurred during decompression On Mon, Sep 9, 2013 at 3:02 PM, James French james.fre...@naturalmotion.com wrote: I tried it again with the 1.8.3 command line and the merge went through... Okay, I'm happy for you that it worked :-). However, I'm not convinced the error is gone. In my case it would also only fail intermittently. I couldn't reproduce it all the time (it happened perhaps 1 in 4 or 5 attempts). If you would run into the error again, please let us know ... (in my case, we were able to reduce the reproduction recipe, by only doing an 'svn export --depth=immediates http://svn.apache.org/repos/asf/subversion/tags/1.8.3/' - within a couple of attempts of that export I would run into the issue (I can reproduce it with both serf 1.2.1 and 1.3.1). Maybe you can also try exactly this export a couple of times?) Tried it with 1.8.3 wandisco about 20 times and it never failed. Tried it with 1.8.1 collabnet and it failed first time. Is the version of serf used dependent on the distro then, and not a core svn thing? Serf 1.3.1 was not released until after SVN 1.8.1 came out. So pretty much anyone's SVN 1.8.1 binaries would be using Serf 1.3.0 or earlier. To answer the general question, while most SVN distros do happen to be using the same versions of most of these dependencies they are nonetheless absolutely dependent on the distro and what version they happen to have used to build the distribution. -- Thanks Mark Phippard http://markphip.blogspot.com/
Username in Repository URL with Serf/ra_serf
Subversion 1.8 throws up errors when I specify HTTP/HTTPS URLs that contain usernames to svn, i.e. svn --username user ls https://server.com/repos/project/ works fine but svn ls https://u...@server.com/repos/project/ results in errors. The same URL worked fine with Neon in 1.7 and older. The exact errors depend on the server I am contacting and the protocol used (HTTP or HTTPS). For example, with a repository hosted with Beanstalk (www.beanstalkapp.com) svn ls https://u...@domain.svn.beanstalkapp.com/repos I get the following errors: svn: E175002: Unable to connect to a repository at URL 'https://u...@domain.svn.beanstalkapp.com/repos' svn: E175002: Unexpected HTTP status 500 'Internal Server Error' on '/repos' svn: E175002: Additional errors: svn: E175002: OPTIONS request on '/repos' failed: 500 Internal Server Error Attempting a similar request with CloudForge: svn ls https://u...@domain.svn.cloudforge.com/repos I get the following errors: svn: E175002: Unexpected HTTP status 405 'Method Not Allowed' on '/repos' svn: E175002: Additional errors: svn: E175002: PROPFIND request on '/repos' failed: 405 Method Not Allowed In both cases the request works as expected when the user is removed from the URL. I have been able to successfully connect to an internal test server via HTTP with basic authentication but attempting the same request via HTTPS with client certificate-based authentication results in the following errors: svn: E175002: Unable to connect to a repository at URL 'https://user@192.168.4.240/repos' svn: E175002: Unexpected HTTP status 400 'Bad Request' on '/repos' These errors are output *after* the client certificate path and passphrase prompts. The fact that 1.7/Neon supported such URLs indicates that this is a significant regression in 1.8. Can anyone throw any light on the cause of these errors? Is this a known issue with Serf/ra_serf? Some additional info: - This behavior is not specific to svn 1.8: 1.7.10 generates the same errors when ra_serf is enabled. - This behavior is specific to Serf. I do not get the same errors with Neon/ra_neon in 1.4, 1.5, 1.6 or 1.7. - All tests were done on Mac OS X 10.8. - 1.8 behavior was tested using a) 1.8.1 binaries we built from source and b) 1.8.1 binaries downloaded from WANdisco. I don't believe that this behavior is specific to our svn build. - 1.7 behavior was tested using 1.7.10 binaries built and distributed by Apple with Xcode 5. - I have tested a build of 1.8.1 with Serf 1.3.1 but experience the same errors. Many thanks, Simon
Re: Breaking up a monolothic repository
On Mon, Sep 9, 2013 at 8:03 AM, Grierson, David david.grier...@bskyb.com wrote: I can see Trent's view point that people are weird and get freaked out by the unexpected (where they might expect the revision numbers to be relatively low). I could see that for someone who had never used subversion before and did not understand the concept of global revision numbers, but not for anyone who has used a multi-project repository. I guess what we should be providing him are points like you do make to help him sell why this isn't an issue to the end users. Like Les says, if someone performs a large batch of commits to a particular branch then the trunk revision numbers are going to leap forward (unexpectedly). So what to sell those folks concerned about it is that they're experiencing this already. Revision numbers aren't something you guess at or expect anything from. They are only useful in terms of the repository history, and it doesn't matter if your project runs sequentially or not. If you want names/numbers that make human sense, you'll be copying to tags for easier reference anyway. -- Les Mikesell lesmikes...@gmail.com
RE: Reverse merge with 1.8.3 yielded tree conflicts
Thanks for the explanation Stefan. Glad svn is working properly :-) -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: 09 September 2013 15:55 To: James French Cc: users@subversion.apache.org Subject: Re: Reverse merge with 1.8.3 yielded tree conflicts On Mon, Sep 09, 2013 at 02:37:05PM +0100, James French wrote: Hi, I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts when a sync up merge was reverted. I ran the merge again with 1.8.3 to confirm the issue and again using 1.7.8 command line (which worked). See the status reports below (a bit hacked manually to remove some sensitive stuff but hopefully there's enough to get an idea). Looks like a regression. No, this is a feature, not a regression. It is listed in CHANGES as: * tree conflicts on directories detected better during merges (issue #3150) Short story is that 1.7 was deleting subtrees during merges without considering the contents of what was being deleted. Whereas 1.8 flags a tree conflict if the subtree being deleted during a merge differs from what the commit being merged was deleting on the merge source branch. This allows you to verify whether the deletion of that subtree is in fact desired within the context of the merge target. In Subversion 1.7, users who were concerned about that had to manually verify every deleted subtree before committing the result of a merge. The purpose of these new tree conflicts flagged by 1.8 is to point out the deleted subtrees which might require such manual verification. In your case, you seem to be fine with the deletion of the affected subtrees. So you can run this to resolve the conflict for each subtree, for example: svn resolve --accept working SceneInteraction # clear conflict marker svn rm SceneInteraction # delete what should be deleted In the future, we hope to improve the UI to better guide users during interactive resolution of these conflicts.
Re: Reverse merge with 1.8.3 yielded tree conflicts
On Mon, Sep 09, 2013 at 02:37:05PM +0100, James French wrote: Hi, I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts when a sync up merge was reverted. I ran the merge again with 1.8.3 to confirm the issue and again using 1.7.8 command line (which worked). See the status reports below (a bit hacked manually to remove some sensitive stuff but hopefully there's enough to get an idea). Looks like a regression. No, this is a feature, not a regression. It is listed in CHANGES as: * tree conflicts on directories detected better during merges (issue #3150) Short story is that 1.7 was deleting subtrees during merges without considering the contents of what was being deleted. Whereas 1.8 flags a tree conflict if the subtree being deleted during a merge differs from what the commit being merged was deleting on the merge source branch. This allows you to verify whether the deletion of that subtree is in fact desired within the context of the merge target. In Subversion 1.7, users who were concerned about that had to manually verify every deleted subtree before committing the result of a merge. The purpose of these new tree conflicts flagged by 1.8 is to point out the deleted subtrees which might require such manual verification. In your case, you seem to be fine with the deletion of the affected subtrees. So you can run this to resolve the conflict for each subtree, for example: svn resolve --accept working SceneInteraction # clear conflict marker svn rm SceneInteraction # delete what should be deleted In the future, we hope to improve the UI to better guide users during interactive resolution of these conflicts.
Re: Breaking up a monolothic repository
On Sep 9, 2013, at 07:31, Les Mikesell wrote: On Sun, Sep 8, 2013 at 8:13 PM, Trent W. Buck wrote: I'm stuck. Since it's no fun to have tens of thousands of empty revs in each project repo, my current approach is to leave existing projects in the monolithic repo, and new projects get separate repos. Why do you think an empty rev will bother anyone any more in a per-project rev that having the rev number jump from a commit to an unrelated project does in the combined repo?It shouldn't be a problem in either case. Rev numbers for any particular use don't need to be sequential, you just need to know what they are. This is true. Heck, if you use a dvcs like git or hg you'll get a completely random revision number (shaped like a sha1 hash) every time. As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. There are also some reasons why keeping the revision number from the old monolithic repository in your new repositories (with empty padding revisions in between) is a really good idea. Have you ever referenced revision numbers in your issue tracker (fixed in r111; r222 broke xyz) or in emails (can you explain what you did in r333; r444 is a great example of abc) or in commit messages (reverted r555; added file forgotten in r666)? If so, you don't want to renumber revs, because that would invalidate all those references.
Re: Breaking up a monolothic repository
Ryan Schmidt subversion-20...@ryandesign.com writes: As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. I think that's the crux of it. Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split.
Re: Breaking up a monolothic repository
Thorsten Schöning tschoen...@am-soft.de writes:
Tell us about the size of your repo
it's format version and primary data types versioned
(Sorry for not giving this info earlier, and shifting the goal posts --
I personally went rcs-arch-darcs-git and never really used svn, so
I'm feeling pretty noob attacking this problem.)
du reports it is 18GiB. The current revno is 16115.
$ grep . /home/svn/PI/{format,db/fs-type,db/format}
/home/svn/PI/format:5
/home/svn/PI/db/fs-type:fsfs
/home/svn/PI/db/format:4
/home/svn/PI/db/format:layout sharded 1000
As to what kind of files are in there -- I'm not actually sure.
Just doing a dumb look at HEAD's list of files,
$ svn ls -R file:///home/svn/PI | wc -l
269281
And looking at the most common extensions:
$ svn ls -R file:///home/svn/PI | sed -n 's/.*\.//p' |
sort | uniq -c | sort -nr | head -20
36581 h 2438 txt
21732 patch 2375 sh
17621 html 2362 i
15023 c 2121 bmp
8143 py 1957 mk
3919 cpp1932 po
3559 png1916 class
3074 gif1813 lua
2950 xml1742 cs
2585 properties 1613 hpp
Obviously that's not weighted by size, and completely ignores anything
that's not in HEAD anymore.
* * *
It's currently hosted on an Ubuntu 10.04 server, so my server svn is
quite old:
subversion 1.6.6dfsg-2ubuntu1.3
apache22.2.14-5ubuntu8.12
I believe some of the users have svn 1.7 on their desktops, but not all.
I'm partway through provisioning the replacement Debian 7 server, which
will have
subversion 1.6.17dfsg-4+deb7u3
apache22.2.22-13
...hm, still 1.6. Is it worth me backporting a newer svn?
I found a bug?about resolve conflict~
(1)myeclipse1 create java file content:
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
System.out.println(2);
System.out.println(3);
System.out.println(4);
System.out.println(5);
System.out.println(6);
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
commit it to test1 repository
(2)checkout test1 repository to desktop test22 directiroy.
(3)test22 import to myeclipse2 and edit java file content:
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
System.out.println(2 2);
System.out.println(3 2);
System.out.println(4 2);
System.out.println(5);
System.out.println(6);
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
commit to test1 repository.
(4)show myeclipse1 Test.java file edit it content:
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
System.out.println(2);
System.out.println(3);
System.out.println(4 1);
System.out.println(5 1);
System.out.println(6 1);
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
and invoke Update menu.
content change bottom:
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
.mine
System.out.println(2);
System.out.println(3);
System.out.println(4 1);
System.out.println(5 1);
System.out.println(6 1);
===
System.out.println(2 2);
System.out.println(3 2);
System.out.println(4 2);
System.out.println(5);
System.out.println(6);
.r4
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
(5)invoke maked resolved menu,checked Resolve conflicts in local file
with my changes option, Test.java file content change bottom:
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
System.out.println(2);
System.out.println(3);
System.out.println(4 1);
System.out.println(5 1);
System.out.println(6 1);
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
(6)My question is, why don't you into the following this?
package test;
public class Test {
public static void main(String[] args) {
System.out.println(1);
System.out.println(2 2);
System.out.println(3 2);
System.out.println(4 1);
System.out.println(5 1);
System.out.println(6 1);
System.out.println(7);
System.out.println(8);
System.out.println(9);
System.out.println(10);
}
}
(7)Thank you lot~
1.8.3 depth_test.py failure on OS X
I built 1.8.3 from the source tar ball and then ran make check. I'm using 10.8.4 with Xcode 4.6.3. depth_test.py fails with: W: svn: E200030: sqlite[S4]: callback requested query abort W: svn: E200030: Additional errors: W: svn: E200030: sqlite[S4]: callback requested query abort W: CWD: /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline W: EXCEPTION: Failure: Command failed: /Volumes/Data/Install/subversion-1.8.3/subversion/svn/svn up --set-depth empty ...; exit code 1 Traceback (most recent call last): File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/main.py, line 1550, in run rc = self.pred.run(sandbox) File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/testcase.py, line 176, in run return self.func(sandbox) File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/depth_tests.py, line 2012, in fold_tree_with_unversioned_modified_items '--set-depth', 'empty', A_path) File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/actions.py, line 865, in run_and_verify_update exit_code, output, errput = main.run_svn(error_re_string, 'up', *args) File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/main.py, line 682, in run_svn *(_with_auth(_with_config_dir(varargs File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/main.py, line 365, in run_command None, *varargs) File /Volumes/Data/Install/subversion-1.8.3/subversion/tests/cmdline/svntest/main.py, line 557, in run_command_stdin '; exit code ' + str(exit_code)) Failure: Command failed: /Volumes/Data/Install/subversion-1.8.3/subversion/svn/svn up --set-depth empty ...; exit code 1 FAIL: depth_tests.py 30: unversioned modified items left untouched Does anybody know what the issue is? Has anybody had success otherwise with this combo? ++ | Alexander M. Rosenbergmailto:al...@leftfield.org | | Nobody cares what I say, so no disclaimer appears here.|
Re: Breaking up a monolothic repository
trentb...@gmail.com (Trent W. Buck) writes: So then I thought to chain the two approaches. This didn't work -- the empty revs were not removed. I guess svndumpfilter --drop-empty-revs is only smart enough to drop the revs that have just *become* empty? rm -rf delete-me-3 svnadmin create delete-me-3 svnadmin dump delete-me-2 | svndumpfilter --drop-empty-revs exclude /canthappen | svnadmin load delete-me-3 A helpful offlist correspondent noted svn 1.8 has --drop-all-empty-revs, so I might try building that long enough to try that option.
Re: Breaking up a monolothic repository
On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote: Ryan Schmidt subversion-20...@ryandesign.com writes: As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. I think that's the crux of it. Have you checked if the users have/need anything (emails, ticket system, etc.) that refer to specific revisions or the history of changes made there? It seems kind of drastic to throw that away because you think the numbers aren't pretty enough. Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split. How does this work now in the combined repository? -- Les Mikesell lesmikes...@gmail.com
Re: Breaking up a monolothic repository
Les Mikesell lesmikes...@gmail.com writes: On Mon, Sep 9, 2013 at 7:23 PM, Trent W. Buck trentb...@gmail.com wrote: Ryan Schmidt subversion-20...@ryandesign.com writes: As someone used to Subversion's usually sequential revision numbers, that bugs me aesthetically, but it works fine. I think that's the crux of it. Have you checked if the users have/need anything (emails, ticket system, etc.) that refer to specific revisions or the history of changes made there? It seems kind of drastic to throw that away because you think the numbers aren't pretty enough. That is an extremely valid point. I'll check. Also part of the reason to split up the repos is to make access control easier, and it looks bad if Alice (who should have access to project 1 but not project 2) can see Bob's old commit metadata to project 2, even if she can't see the commit bodies after the split. How does this work now in the combined repository? Right now, they don't have it with the combined repo. Anyone in the svn group can read everything. (This is one of the reasons they want to break up the single repo into per-project repos.)
