Re: Removing code online
Guten Tag Sam Khan, am Mittwoch, 2. Oktober 2013 um 03:25 schrieben Sie: There's online code that's being copied by others. https://subversion.assembla.com/svn/cs4410-als364/ Is it possible you can remove the code for CS 4410 project MP1,MP2,MP3,MP4 No, this is public repo from assembla, if they don't want it public they need to restrict access. If you think this is a mistake you should contact assembla. 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
Checkout to root folder causes sequence of exceptions:
Hi, I performed a Checkout on windows to the root of a drive and received a sequence of exceptions. Workaround was to make a folder for the working copy. === --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_wc\wc_db.c' line 13212: assertion failed (svn_dirent_is_absolute(local_abspath)) --- OK --- === --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative)) --- OK --- === --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative)) --- OK --- === --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.2\ext\subversion\subversion\libsvn_subr\dirent_uri.c' line 1571: assertion failed (! svn_path_is_url(relative)) --- OK --- With kind regards, met vriendelijke groeten, Maurice Beelen Software Architect ___ Sioux. Source of your Technology Technical Software | Electronics | Industrial Mathematics | Remote Solutions Sioux Embedded Systems B.V. Esp 405 5633 AJ Eindhoven The Netherlands www.sioux.euhttp://www.sioux.eu/ (navigation)http://maps.google.com/maps?q=sioux+eindhovenhl=enie=UTF8view=mapf=ddaddr=Esp+405,+5633+AJ+Eindhoven,+Netherlands+(Sioux+Embedded+Systems+B.V.)geocode=CR5KabnN4tr4FYWkEQMdz8FTACH9IEpbInwENgt=mz=16vpsrc=0 Sioux applies general terms and conditions (GTC). Our liability is limited to the extent mentioned in the GTC. Please see: www.sioux.euhttp://www.sioux.eu/.
RE: Subversion 1.8 httpd.exe taking 100% CPU
Hello Pavel, Any update on this issue as the bug still exists? From: Dinesh Hirani Sent: 04 July 2013 16:30 To: 'Pavel Lyalyakin'; users@subversion.apache.org Subject: RE: Subversion 1.8 httpd.exe taking 100% CPU Hello Pavel, Answer is in red below -Original Message- From: Pavel Lyalyakin [mailto:pavel.lyalya...@visualsvn.com] Sent: 04 July 2013 16:19 To: users@subversion.apache.orgmailto:users@subversion.apache.org; Dinesh Hirani Subject: Re: Subversion 1.8 httpd.exe taking 100% CPU Hello Dinesh, We just upgraded subversion from 1.7 to 1.8 and noticed that the process httpd.exe takes 100% and maxes the box and we have to keep killing the httpd.exe, are you aware of this problem? * What's your environment (svn client / server / Apache HTTP Server version)? We using TortoiseSVN 1.8 / CollabNet Edge / Apache HTTP Server version 2.4.4 * What exactly do you do when the httpd.exe starts to consume 100% CPU time? We don't know exactly what causes it because nothing is written to any logs as far we can see, however once we kill the httpd.exe then it's find for another couple of hours. * Any related events on the server log? Error log Last message logged. Then at 9.35 I killed httpd.exe [Thu Jul 04 09:24:49.798629 2013] [authz_svn:error] [pid 4844:tid 892] [client 10.9.11.84:56153] Access denied: 'bparker' OPTIONS risk-dev:/Build/trunk/RabbitMQ [Thu Jul 04 09:35:45.690450 2013] [mpm_winnt:notice] [pid 4204:tid 480] AH00428: Parent: child process 4844 exited with status 4294967295 -- Restarting. Subversion log Last message logged. Then at 9.35 I killed httpd.exe [04/Jul/2013:09:33:52 +0100] svc-teamcity Risk-DEV log (/) r41581:41690 discover-changed-paths revprops=all 0 [04/Jul/2013:09:35:02 +0100] svc-teamcity Risk-DEV log (/) r41581:41690 discover-changed-paths revprops=all 0 -- With best regards, Pavel Lyalyakin VisualSVN Team The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access by any other person to this e-mail is not authorized. If you are not the intended recipient, please delete this e-mail. Any disclosure of this e-mail or of the parties to it and any copying or distribution of it is prohibited (and may be unlawful). The information expressed herein may be changed at any time without notice or obligation to update. We do not represent that this message is virus-free, complete or accurate and it should not be relied upon as such. Electronic communications may be monitored for operational and business purposes to the extent permitted by applicable law. This email does not constitute legal or tax advice, and the information contained in this communication should not be regarded as such. Decura IM LLP is authorised and regulated by the Financial Conduct Authority. Registered office address: 11-12 St James's Square, London SW1Y 4LB. Registered in England and Wales: OC375344 Decura LLP is authorised and regulated by the Financial Conduct Authority. Registered office address: 11-12 St James's Square, London SW1Y 4LB. Registered in England and Wales: OC377231
Re: Breaking up a monolothic repository
Am 10.09.2013 19:45, schrieb Thomas Harold: When we moved from a monolithic repository to per-client repositories a few years ago, we went ahead and: - Rebased the paths up one or two levels (old system was something like monolithicrepo/[a-z]/[client directories]/[job directory]) so that the urls were now clientrepo/[job directory]. That was a tricky thing to do and we had to 'sed' the output of the dump filter before importing it back. It broke a few things, such as svn:externals which were not relative-pathed, but was worth it in the long run so that our URLs got shorter. - Made sure that the new repos all had unique UUIDs. - Renumbered all of the resulting revisions as we loaded things back in. But we didn't have to deal with any bug tracking systems that referred to a specific revision. And having lower revision numbers was preferred, along with dropping revisions that referred to other projects. I'm now facing the same problem. My users want the rebasing, but during the dump/load instead of after the fact (apparently, it causes issues with their environment when they need to go back to an earlier revision to reproduce something). They also want to keep the empty revisions (for references from the issue tracker). I haven't tried it with svnadmin dump followed by svndumpfilter (I don't think it has that capability). I've tried svnrdump (from svn 1.7), it resulted in either a new repository with the full path included (rdump/load all revs) or an interesting failure mode with a missing node during a copy operation when rdump -r revision_after_path:HEAD was used I've also tried using svnsync, but that also results in the full path included, no rebasing. How did you do it? Also, am I missing something that has been included in a current svn version? Cheers, Ulli -- Ullrich Jans, Specialist, IT-A Phone: +49 9131 7701-6627, mailto:ullrich.j...@elektrobit.com Fax: +49 9131 7701-6333, www.elektrobit.com Elektrobit Automotive GmbH, Am Wolfsmantel 46, 91058 Erlangen, Germany Managing Directors: Alexander Kocher, Gregor Zink Register Court Fürth HRB 4886 Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
RE: Breaking up a monolothic repository
Am 10.09.2013 19:45, schrieb Thomas Harold: When we moved from a monolithic repository to per-client repositories a few years ago, we went ahead and: - Rebased the paths up one or two levels (old system was something like monolithicrepo/[a-z]/[client directories]/[job directory]) so that the urls were now clientrepo/[job directory]. That was a tricky thing to do and we had to 'sed' the output of the dump filter before importing it back. It broke a few things, such as svn:externals which were not relative-pathed, but was worth it in the long run so that our URLs got shorter. - Made sure that the new repos all had unique UUIDs. - Renumbered all of the resulting revisions as we loaded things back in. But we didn't have to deal with any bug tracking systems that referred to a specific revision. And having lower revision numbers was preferred, along with dropping revisions that referred to other projects. I'm now facing the same problem. My users want the rebasing, but during the dump/load instead of after the fact (apparently, it causes issues with their environment when they need to go back to an earlier revision to reproduce something). They also want to keep the empty revisions (for references from the issue tracker). Wouldn't it be much simpler to keep the current repository as a read only archives and move the HEAD of each project into its own repo? I haven't tried it with svnadmin dump followed by svndumpfilter (I don't think it has that capability). I've tried svnrdump (from svn 1.7), it resulted in either a new repository with the full path included (rdump/load all revs) or an interesting failure mode with a missing node during a copy operation when rdump -r revision_after_path:HEAD was used I've also tried using svnsync, but that also results in the full path included, no rebasing. How did you do it? Also, am I missing something that has been included in a current svn version? Cheers, Ulli
