RE: How Big A Dump File Can Be Handled?
> From: Ben Reser > Sent: Wednesday, 21 August 2013 12:12 PM > On Tue Aug 20 16:44:08 2013, Geoff Field wrote: > > I've seen some quite large dump files already - one got up > > to about 28GB. The svnadmin 1.2.3 tool managed to cope with > > that quite successfully. Right now, our largest repository > > (some 19,000 revisions with many files, including > > installation packages) is dumping. In the 5300 range of > > revisions, the dump file has just passed 9GB. Overall, it got to about 29GB. Dump and load worked fine, although they got a bit slow towards the end. (In fact, I delayed sending this until it had actually finished.) > Shouldn't be a problem within the limits of the OS and filesystem. I've just realised that my concern was based on a power-of-2 limitation that means that a 32-bit signed integer would roll over at the 2GB mark, with an unsigned roll-over at 4GB. It's possible the Windows Server 2003 file system might have started to complain when it ran out of block indices/counters or some such, but there's no reason a 32GB+ file won't work if 4.1GB or more works. > However, I'd say why are you bothering to produce dump files? > Why not simply pipe the output of your dump command to a > load command, e.g. > > svnadmin create newrepo > svnadmin dump --incremental oldrepo | svnadmin load newrepo I've been working in Windoze too long - I failed to think of that option. I'll use that for the rest of the repositories (about 19 remain to be done). Thank you for that application of the clue-by-four. You've made the rest of my task a lot easier. I really should have done it all using a scripting language of some sort, too. I've told myself it's really too close to the end of the process to think of *that* change now, except I've just managed to quickly throw together a batch file to do the job. I could probably have done it in python or some other scripting language, but batch files are quick and easy. Again, thanks Ben for the prompt to use my head a bit better (even though you didn't explicitly suggest this aspect). CopyBDBToFSFS.bat: rem Create a new repository - using the OLD format just in case we need to switch back to the old server "C:\Program Files\Subversion\bin\svnadmin.exe" create "%1_FSFS" rem Copy the data from the old repository to the new one "C:\Program Files\Subversion\bin\svnadmin.exe" dump --incremental "%1" | "C:\Program Files\Subversion\bin\svnadmin.exe" load "%1_FSFS" rem Change the names to make the new repository accessible using the existing authentication and URLs and the old one accessible for emergency use. ren "%1" "%1_BDB" ren "%1_FSFS" "%1" rem Check the new repository with the current tools to confirm it's OK. svnadmin verify "%1" Note that we have the old version 1.2.3 server software installed at the C:\Program Files\Subversion location, and later versions are stored under other locations, with the path set to point to the new version. I'm creating the new repositories with the old version for those (hopefully rare) occasions when we need to switch back to the old server version. > You'll need space for two repos but that should be less than > the space the dump file will take. We're keeping the old repos anyway, just in case. We're an automotive parts company with support requirements for some quite old versions, so we can't afford to throw away too much history. Even though it's a RAID system (using Very Expensive disk drives, so it's actually a RAVED system), there's lots of space available on the drive where the repositories live. > I included the > --incremental option above because there's no reason to > describe the full tree for every revision when you're doing a > dump/load cycle. That makes sense. > You can save space with --deltas if you > really want the dump files, but at the cost of extra CPU time. > If you're just piping to load the CPU to calculate the delta > isn't worth it since you're not saving the dump file. I agree. The server's not particularly new, so if I can save on processor time that's a good thing. I'm discarding/reusing the dump files anyway, since we're keeping the original repositories (and we have a separate backup system for the servers - I know it works too, because I've had to restore some of the BDB repositories from it). Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication i
Re: svn 1.8.1: segmentation fault on merge
On Tue Aug 20 08:09:02 2013, John Jacobson wrote: > I am encountering the crash described below when doing a particular > merge. I've tried the merge on a clean checkout - it still segfaults. > The same merge succeeds with svn 1.7.8. What are the steps that I > should take in order to file a meaningful issue report? If you're able to build from source the best report can be to build Subversion by passing --enable-maintainer-mode to configure and then running the merge via gdb. You don't need to install the version with debugging symbols to do this (just configure and make). The following should do the trick (where BUILDDIR is where you built subversion): libtool e gdb --args $BUILDDIR/subversion/svn/svn merge ^/offline/asmm/branches/uat/Production --verbose After gdb starts type r and press enter. You should get a backtrace when the segfault happens. Post the backtrace here. That is going to be the best way. If you can't do that you're probably going to have to try and describe the changes that are being merged. If you can find a way to reproduce it from a fresh repo with minimal steps that's even better.
Re: How Big A Dump File Can Be Handled?
On Tue Aug 20 16:44:08 2013, Geoff Field wrote: > I've seen some quite large dump files already - one got up to about 28GB. > The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right > now, our largest repository (some 19,000 revisions with many files, including > installation packages) is dumping. In the 5300 range of revisions, the dump > file has just passed 9GB. Shouldn't be a problem within the limits of the OS and filesystem. However, I'd say why are you bothering to produce dump files? Why not simply pipe the output of your dump command to a load command, e.g. svnadmin create newrepo svnadmin dump --incremental oldrepo | svnadmin load newrepo You'll need space for two repos but that should be less than the space the dump file will take. I included the --incremental option above because there's no reason to describe the full tree for every revision when you're doing a dump/load cycle. You can save space with --deltas if you really want the dump files, but at the cost of extra CPU time. If you're just piping to load the CPU to calculate the delta isn't worth it since you're not saving the dump file.
Re: Cannot check out public directory with client 1.8.x without access to repo root
Hi Ivan, On Tue, Aug 20, 2013 at 12:02 AM, Ivan Zhakov wrote: > On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov wrote: >> On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida >> wrote: [...] >>> The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. >>> Our repository (let's call it "myrepo") allows public read access (* = >>> r) to myrepo/trunk, but not to myrepo/ (the root). There is also a >>> directory myrepo/trunk/secret to which only specific users have access >>> to. >>> >>> Everything has been working as expected with SVN 1.6 and 1.7 clients: >>> in particular, no username or password is requested when checking out >>> myrepo/trunk. >>> >>> However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check >>> out any directory without supplying the credentials of a user who has >>> access to the repository root. >>> >>> svn co https://our.server.com/svn/myrepo/trunk -> Requires >>> authentication with client 1.8.x but not with 1.6.x or 1.7.x >>> svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 >>> svn list https://our.server.com/svn/myrepo -> Requires auth, as expected [...] >>> The following is the section of ssl_access_log produced by checking >>> out myrepo/trunk using client 1.6.18 (OS X): >>> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS >>> /svn/myrepo/trunk HTTP/1.1" 200 197 >> [...] >>> /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 >>> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND >>> /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 >>> >>> And the following is the section of ssl_access_log produced by >>> checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows >>> 7): >>> xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS >>> /svn/myrepo/trunk HTTP/1.1" 200 197 >> [...] >>> xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND >>> /svn/myrepo/!svn/bc/123 HTTP/1.1" 401 483 > It should be "403 Forbidden", not "401 Unauthorized". Looks like some > issue with server configuration. I can get the server to return 403 Forbidden for https://our.server.com/svn/myrepo by removing "Require valid-user" from our Apache config. This does seem to allow the anonymous checkout of https://our.server.com/svn/myrepo/trunk to succeed. But this also prevents the client from asking for a password altogether when checking out e.g. https://our.server.com/svn/myrepo, which is not the desired behavior. >>> It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to >>> which access is denied (401), whereas client 1.6.18 only ever requests >>> /svn/myrepo/!svn/bc/123/trunk, to which access is granted. >>> >> Most likely it is some problem with inherited properties feature >> implemented in Subversion 1.8. >> > The issue doesn't reproduces with server configured for non-anonymous > access: the server returns 401 Forbidden for PROPFIND request on > repository root and handled properly by Subversion 1.8 client. (I assume you meant 403 Forbidden.) Does that still allow checking out the root by users who do have read permission for the root? Can you perhaps spot an error in my authz and apache configs (please see my reply to Daniel)? Thanks for the help, Mark
Re: Cannot check out public directory with client 1.8.x without access to repo root
Hi Daniel, On Mon, Aug 19, 2013 at 12:06 PM, Daniel Shahaf wrote: > Mark Tsuchida wrote on Mon, Aug 19, 2013 at 11:19:42 -0700: >> svn co https://our.server.com/svn/myrepo/trunk -> Requires >> authentication with client 1.8.x but not with 1.6.x or 1.7.x >> svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 >> svn list https://our.server.com/svn/myrepo -> Requires auth, as expected >> >> The 1.8.x clients can successfully check out myrepo/trunk if a >> username and password are given, for a user with access to the >> repository root. [...] > Information that might be relevant includes: > > - The authz file > - The block Thanks for the suggestions. I've been able to simplify the authz file to the following without changing the problematic behavior: -- begin -- [myrepo:/] mark = rw * = [myrepo:/trunk] * = r mark = rw [/] mark = rw * = -- end -- The block looks like this: -- begin -- DAV svn SVNParentPath /home/svnroot SSLRequireSSL AuthType Basic AuthName "Repository" AuthUserFile /etc/httpd/httpdsvnpasswd AuthzSVNAccessFile /etc/httpd/svnAccess Satisfy Any Require valid-user -- end -- > - Whether 1.7.x reproduces the problem under either serf and neon (did > you test with each of them?) I tried compiling SVN 1.7.11 with serf 1.3.1 and neon 0.29.6. Both work fine: $ ~/tmp/bin/svn --config-option servers:global:http-library=serf co https://our.server.com/svn/myrepo/trunk # -> OK $ ~/tmp/bin/svn --config-option servers:global:http-library=neon co https://our.server.com/svn/myrepo/trunk # -> OK > - Whether the problem reproduces with 1.6.17 > > Also, you should upgrade to at least 1.6.17, if not 1.7.11 or 1.8.1, to > pick up fixes to security issues. (An upgrade to at least 1.7 could > easily fix your problem, too, since it'll enable 1.7+ clients to talk > HTTPv2, which will avoid the HTTP-non-v2 compatibility codepath (unless > you have 1.6 clients too...).) I haven't had a chance to test this yet. I see your point about upgrading, but it would be nice if we could keep 1.6.11, which is the default version on CentOS/RHEL 6.4, unless this turns out to be a true incompatibility. Mark
How Big A Dump File Can Be Handled?
Just a query out of curiosity: I'm currently in the process of migrating all 74 of our BDB repositories to FSFS via a dump/create/load cycle. I've seen some quite large dump files already - one got up to about 28GB. The svnadmin 1.2.3 tool managed to cope with that quite successfully. Right now, our largest repository (some 19,000 revisions with many files, including installation packages) is dumping. In the 5300 range of revisions, the dump file has just passed 9GB. Am I going to run into problems, or is it open-ended? This probably comes down to the data type of the file index parameters/variables. I guess I'll find out soon enough, as the dump churns away (and, if/when that succeeds, the subsequent load churns through). Just in case any developer is on hand during my work day here in Australia, it might be nice to know. I'll let the list know if there's a crash during the process, too. Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department. - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files.
svn 1.8.1: segmentation fault on merge
I am encountering the crash described below when doing a particular merge. I've tried the merge on a clean checkout - it still segfaults. The same merge succeeds with svn 1.7.8. What are the steps that I should take in order to file a meaningful issue report? $ svn merge ^/offline/asmm/branches/uat/Production --verbose --- Merging *Segmentation fault* $ svn info . Path: . Working Copy Root Path: URL: Relative URL: ^/offline/asmm/trunk/Production Repository Root: Repository UUID: 3c33d142-4166-11dd-ac8f-de326a75b49c Revision: 180446 Node Kind: directory Schedule: normal $ svn info ^/offline/asmm/branches/uat/Production Path: Production URL: Relative URL: ^/offline/asmm/branches/uat/Production Repository Root: svn://etgsvn/etg Repository UUID: 3c33d142-4166-11dd-ac8f-de326a75b49c Revision: 180449 Node Kind: directory (Compiled & running on CentOS 6.2) $ svn --version svn, version 1.8.1 (r1503906) compiled Aug 16 2013, 14:07:12 on x86_64-unknown-linux-gnu Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme
Re: Switching
Guten Tag John Maher, am Dienstag, 20. August 2013 um 19:33 schrieben Sie: > For example, when I switch to branch P it switches OK. Where did you switch from? Does this branch contain the directory which is responsible for the later mentioned error message? It has been created by someone of course, either by svn because it's part of branch or by something other like a build tool. > An svn > status on the problem directory shows it with a '?'. Then I switch > to branch E and get a conflict. It says "local unversioned, > incoming add upon switch". Which is correct behavior as the director is present, but not versioned. > The local should be unversioned, it is > not part of branch P. I do not know why the directory did not get > deleted during the switch. Surely because it contained unversioned data itself and therefor couldn't be deleted by svn as it tries to never delete unversioned data. > Svn revert does not do anything useful. So I then issue svn > resolve --accept working UI_Email where UI_Email is the directory > causing the problems. This clears the conflict. Of course, that's what resolve is meant for ;-), but the interesting thing is the data in the directory. It may not contain all the files and dirs need from your branch E where the directory is versioned in. > Then I switch to branch P. Then is says "local delete, incoming > delete". Why it has a local delete is beyond me. This could be because your conflict resolution which may be missing data which should be present in the director yin branch E, an is not in your local working copy. This means something has changed but didn't get committed because you switched instead of first committing the changes from your conflict resolution. > So I resolve the conflict then commit and decide to let subversion > delete the directory (I have a backup because I've lost code to > subversion before). You never lose code unless you lose your repo, the only thing may be that you don't know how to revert to older revisions. ;-) And yes, I often have the same problem using the console applications and prefer using Tortoise instead in those cases. > Then I switch to branch E. No conflict. Of course, because the directory is missing, which is different to what you have described in the start: You switched to branch P from some other branch, which contained the directory and it surely did contain unversioned files which prevented svn from deleting the directory on switching to branch P. > But I won't get my hopes > up yet, I still do not have the new library included which was the > whole reason for creating the branch in the first place. So I copy > over the directory and do a svn add then commit. Then I can switch > to branch P. This is where the problem arises. Subversion deletes > the files but not the directory because it contains files that do > not belong in subversion. That's the info which should have been in the first mail and the start of this one. :-) > I have no control over this as the > compiler puts them there. They are on the global ignore list. And subversion can't know how important those files are for you and therefor can't just delete them. This problem is up to you, you need to delete them on your own after switching to branch P if you don't need the directory in your working copy. > My question is how to properly handle this? Or is branching > unusable in this situation with out the extra hassle? As subversion can't know what to do with unversioned files, it leaves them as they are where they are. It is up to you to clean up your working copy in such a way that it doesn't contain any mess which prevents you from switching between different branches. 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: Switching
> -Original Message- > From: John Maher [mailto:jo...@rotair.com] > Sent: Tuesday, August 20, 2013 1:33 PM > To: Andrew Reedick; Subversion help > Subject: RE: Switching > > Thanks for your reply. I agree it does not make sense. But it is > reproducible. The dir trees are NOT identical because one branch has a > library that the other does not. In normal use I would expect the > branches to differ. And I assure you one of the branches does not have > the directory causing the trouble, I checked on the server. > > So the branches are different and it appears impossible to switch > between them without conflicts. > > For example, when I switch to branch P it switches OK. An svn status > on the problem directory shows it with a '?'. Then I switch to branch > E and get a conflict. It says "local unversioned, incoming add upon > switch". The local should be unversioned, it is not part of branch P. > I do not know why the directory did not get deleted during the switch. > An svn status shows the directory marked for deletion. So in one > instance of time I get a message of a directory that is unversioned, > incoming add, marked for deletion. When removing dirs, switch will not delete local/private/unversioned files. If there is a local file in a dir tree, then all the versioned files will be removed from your workspace, but a local tree will remain with the local files still in it. That's mostly likely why you see a '?' after the switch. Ex: 1. 'this_dir' exists in current workspace as a versioned dir tree. 2. 'this_dir' does NOT exist in branch P. 3. touch this_dir/hello_world.txt 3. svn switch ^/branches/P 4. svn status: " ? this_dir" The only file under "this_dir" will be hello_world.txt. All other versioned files/dirs will have been removed. > > Svn revert does not do anything useful. So I then issue svn resolve -- > accept working UI_Email where UI_Email is the directory causing the > problems. This clears the conflict. > > Then I switch to branch P. Then is says "local delete, incoming > delete". Why it has a local delete is beyond me. That folder is part > of the branch, I want it there and never issued a delete. But > subversion did. So I resolve this conflict the same as the last one > and switch back to branch E. You guessed it, conflict again. You shot yourself in the foot. =) The local copy of the dir prevented switch from running the add. (Switch wasn't able to pull in the versioned copy of the dir.) Then you didn't fix the dir conflict by manually running 'svn copy' yourself to pull in the dir from branch P. When you did the resolve, you told svn that the current state of the dir is correct, and since the current state of the dir was effectively "deleted", you wound up telling svn to delete the file from branch P. Again, when resolving tree conflicts, you need to manually copy/add/delete/mv manipulate the tree into the correct state before resolving the tree conflict. > > So I resolve the conflict then commit and decide to let subversion > delete the directory (I have a backup because I've lost code to > subversion before). So now my code is gone. I delete the directory > with supporting files. Then I switch to branch P. Success for now (I > know failure is just a matter of time). You can recover the deleted versioned dirs and files via peg revisions. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect > Then I switch to branch E. No conflict. But I won't get my hopes up > yet, I still do not have the new library included which was the whole > reason for creating the branch in the first place. Right. You deleted the dir from branch P. And you deleted the local/private files/tree as well. Thus no conflict with branch E. However, if you want to get the dir into branch E, then you should have merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/E/some_dir.) (But you'll need to restore the dir in branch P first via 'svn copy' and a peg revision.) > So I copy over the > directory and do a svn add then commit. Then I can switch to branch P. Argh. No, no, no. That creates "evil twins". What you should have done was 'svn copy svn:///some_dir@1234 some_dir" to add the dir back in. When you run 'svn add' you create brand new objects with no history. Evil twins break merging. > This is where the problem arises. Subversion deletes the files but not > the directory because it contains files that do not belong in > subversion. I have no control over this as the compiler puts them > there. They are on the global ignore list. Svn switch won't delete your local/private files because that would be rude, where rude equals "destroying the user's files." So if you're switching, you need to manage private/local files. Maybe run 'make clean' (assuming you have a clean option) before switching? Or tweak your
Re: using "svn merge", "svn diff", and "svn patch"
On Tue, Aug 20, 2013 at 01:16:40PM -0400, James Hanley wrote: > Not sure if this is a valid operation, but should I be able to use svn > merge, then svn diff to create a patch, then svn patch on another branch > (or pristine checkout of the originating branch where the diff was created) > to create a replica of the merge operation? No. 'svn patch' is not intended to be a drop-in replacement for 'svn merge'. > The reason I ask is that it appears not to do that.. I get an "Skipped > missing target" error on one file that was added with history with the > merge, I guess what happened is that you didn't use the --show-copies-as-adds option for 'svn diff' when you created the diff. svn patch cannot handle copies, only additions, due to restrictions of the unidiff format. > another in the same path that doesn't error or add, and apparently > no mergeinfo included at all. svn patch doesn't support mergeinfo either. See http://subversion.tigris.org/issues/show_bug.cgi?id=3747
RE: Switching
Thanks for your reply. I agree it does not make sense. But it is reproducible. The dir trees are NOT identical because one branch has a library that the other does not. In normal use I would expect the branches to differ. And I assure you one of the branches does not have the directory causing the trouble, I checked on the server. So the branches are different and it appears impossible to switch between them without conflicts. For example, when I switch to branch P it switches OK. An svn status on the problem directory shows it with a '?'. Then I switch to branch E and get a conflict. It says "local unversioned, incoming add upon switch". The local should be unversioned, it is not part of branch P. I do not know why the directory did not get deleted during the switch. An svn status shows the directory marked for deletion. So in one instance of time I get a message of a directory that is unversioned, incoming add, marked for deletion. Svn revert does not do anything useful. So I then issue svn resolve --accept working UI_Email where UI_Email is the directory causing the problems. This clears the conflict. Then I switch to branch P. Then is says "local delete, incoming delete". Why it has a local delete is beyond me. That folder is part of the branch, I want it there and never issued a delete. But subversion did. So I resolve this conflict the same as the last one and switch back to branch E. You guessed it, conflict again. So I resolve the conflict then commit and decide to let subversion delete the directory (I have a backup because I've lost code to subversion before). So now my code is gone. I delete the directory with supporting files. Then I switch to branch P. Success for now (I know failure is just a matter of time). Then I switch to branch E. No conflict. But I won't get my hopes up yet, I still do not have the new library included which was the whole reason for creating the branch in the first place. So I copy over the directory and do a svn add then commit. Then I can switch to branch P. This is where the problem arises. Subversion deletes the files but not the directory because it contains files that do not belong in subversion. I have no control over this as the compiler puts them there. They are on the global ignore list. Now when I switch the conflict returns. Nothing in the book explains how to handle this. Searching comes up with all kinds of irrelevant stuff and unanswered questions. My question is how to properly handle this? Or is branching unusable in this situation with out the extra hassle? Thanks JM -Original Message- From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net] Sent: Tuesday, August 20, 2013 10:17 AM To: John Maher; Subversion help Subject: RE: Switching > From: John Maher [mailto:jo...@rotair.com] > Sent: Monday, August 19, 2013 1:31 PM > To: Subversion help > Subject: Switching > > Hello, > > I want to thank all who have been helpful. I have gotten my test project to > merge branches successfully. Now I am trying it on our production code and > wish to make sure I am not making any mistakes. > > I use one folder for my source code (all branches) mainly because of vendor > requirements the code must be run from the same directory. I have created > two branches for two new features. One feature extends an existing library. > The other feature adds a new library as well as extending an existing one. > When I switch I create a conflict because the directory exists in one branch > and not the other: That doesn't make sense. If you branched (i.e. created copies of a baseline) then the dir trees should be identical. Extending/modifying the library (adding new dirs) shouldn't create a conflict for svn switch, unless you modified the same directory tree/structure in the workspace's branch and in the branch you're switching too. This happens if you 'svn add' the same dir in both branches. Example: Bad, causes conflict: svn add ^/branches/foo/new_dir svn add ^/branches/bar/new_dir Good: Svn add ^/branches/foo/new_dir cd to bar workspace; svn copy ^/branches/foo/new_dir . It could also happen if you renamed/moved the same dir in both branches. > local unversioned, incoming add upon switch This sounds like you have a normal, unversioned directory in the workspace. As part of the switch, svn wants to add a versioned dir of the same name to your workspace. You should be able to rename the local normal dir to a new name in order to let the add operation be run unimpeded. I would 'svn revert -R' the entire workspace[1], rename the normal, local dir, and re-run the switch. And figure out why you have a normal, unversioned copy of the dir in the first place. > This may or may not be what is supposed to happen, that would be the first > thing I would like to know. How to fix it would be the second thing that I > would like to know. Accordi
Re: using "svn merge", "svn diff", and "svn patch"
This was with 1.8.1 client - BTW. On Tue, Aug 20, 2013 at 1:16 PM, James Hanley wrote: > Not sure if this is a valid operation, but should I be able to use svn > merge, then svn diff to create a patch, then svn patch on another branch > (or pristine checkout of the originating branch where the diff was created) > to create a replica of the merge operation? > > The reason I ask is that it appears not to do that.. I get an "Skipped > missing target" error on one file that was added with history with the > merge, another in the same path that doesn't error or add, and apparently > no mergeinfo included at all. > > I can't really share what I've seen since even the file names are > considered proprietary, but I may be able to write a script to reproduce. > > Has this been seen or just not an acceptable use-case? > -Jim >
using "svn merge", "svn diff", and "svn patch"
Not sure if this is a valid operation, but should I be able to use svn merge, then svn diff to create a patch, then svn patch on another branch (or pristine checkout of the originating branch where the diff was created) to create a replica of the merge operation? The reason I ask is that it appears not to do that.. I get an "Skipped missing target" error on one file that was added with history with the merge, another in the same path that doesn't error or add, and apparently no mergeinfo included at all. I can't really share what I've seen since even the file names are considered proprietary, but I may be able to write a script to reproduce. Has this been seen or just not an acceptable use-case? -Jim
RE: Mixing recursive and non-recursive commits
I'm not following why you think this would be inconsistent behavior. The scenarios you listed are all "modified" parents not newly added parents. I'm not requesting an option to always automatically add parents just to add new parents if needed. I don't know of any one requesting "automatic parents" add although I guess you could extend it in the future to that. Would it help to call the option --include-new-parents instead of just --parents? The fact of the matter is there is no option to do this now and to build a list of parents on the command line to checkin a new file down in a large subdir tree is time consuming because you have to specify each potentially new parent tree (even after added locally). Doing a commit at the higher level is obviously not desirable if there are other subdirs there that are added w/ new or modified dirs/files I don't wish to commit now. I understand you are looking for more consensus from others before moving forward with an official request on this. I'm hoping others jump on this thread over time I guess and push for this. All I can point to is others asking/complaining about the lack of support for the same thing: http://stackoverflow.com/questions/8932165/add-and-commit-files-in-a-tree-to-svn http://subversion.1072662.n5.nabble.com/feature-request-svn-ci-parents-option-td69929.html I'll wait awhile to see if others think this is valid but if not I'm fine continue on manually adding parents to the command line checkin. Eric -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: Tuesday, August 20, 2013 9:40 AM To: Braun, Eric Cc: Stefan Sperling; users@subversion.apache.org; Moe, Mark Subject: Re: Mixing recursive and non-recursive commits "Braun, Eric" writes: > If do a google search for "svn commit parents" you'll see I'm not the > first to unofficially request this and come across this issue. I > suspect most others just kludged around this and found a subtree to > checkin with additional work involved. I see the need for this quite > often when I'm running scripts that interactive with multiple > directory trees. Quite often the scripts create new dirs with new > files that I want to checkin. So I add these with --parents. When > completed though I may want to selectively checkin certain files w/ a > given comment (not the whole subtree). > > Regarding your corner cases if we stick to the explanation that only > newly added parent directories (and their properties set) will get > added to the commit list then this handles these scenarios. In the > first scenario the property updates in A would NOT be committed > because A is not a newly added parent directory. In the second corner > case items in the changelist plus any newly added parent directories > is what would be committed. The problem I have is that the simple behaviour leads to inconsistencies such as modified parents with properties. You suggest resolving that inconsistency in a particular way but as far as I can see other behaviours are just as reasonable. You describe the feature as "added parents" but somebody else could describe it as "automatic parents" and want the other behaviour. If we implement one behaviour now how do we extend it in the future? I don't see many requests for this behaviour and in this thread the discussion is mostly you and me. To make progress we need consensus on the desired behaviour and that is hard when there are so few voices. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: Mixing recursive and non-recursive commits
"Braun, Eric" writes: > If do a google search for "svn commit parents" you'll see I'm not the > first to unofficially request this and come across this issue. I > suspect most others just kludged around this and found a subtree to > checkin with additional work involved. I see the need for this quite > often when I'm running scripts that interactive with multiple > directory trees. Quite often the scripts create new dirs with new > files that I want to checkin. So I add these with --parents. When > completed though I may want to selectively checkin certain files w/ a > given comment (not the whole subtree). > > Regarding your corner cases if we stick to the explanation that only > newly added parent directories (and their properties set) will get > added to the commit list then this handles these scenarios. In the > first scenario the property updates in A would NOT be committed > because A is not a newly added parent directory. In the second corner > case items in the changelist plus any newly added parent directories > is what would be committed. The problem I have is that the simple behaviour leads to inconsistencies such as modified parents with properties. You suggest resolving that inconsistency in a particular way but as far as I can see other behaviours are just as reasonable. You describe the feature as "added parents" but somebody else could describe it as "automatic parents" and want the other behaviour. If we implement one behaviour now how do we extend it in the future? I don't see many requests for this behaviour and in this thread the discussion is mostly you and me. To make progress we need consensus on the desired behaviour and that is hard when there are so few voices. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
RE: Switching
> From: John Maher [mailto:jo...@rotair.com]
> Sent: Monday, August 19, 2013 1:31 PM
> To: Subversion help
> Subject: Switching
>
> Hello,
>
> I want to thank all who have been helpful. I have gotten my test project to
> merge branches successfully. Now I am trying it on our production code and
> wish to make sure I am not making any mistakes.
>
> I use one folder for my source code (all branches) mainly because of vendor
> requirements the code must be run from the same directory. I have created
> two branches for two new features. One feature extends an existing library.
> The other feature adds a new library as well as extending an existing one.
> When I switch I create a conflict because the directory exists in one branch
> and not the other:
That doesn't make sense. If you branched (i.e. created copies of a baseline)
then the dir trees should be identical. Extending/modifying the library
(adding new dirs) shouldn't create a conflict for svn switch, unless you
modified the same directory tree/structure in the workspace's branch and in the
branch you're switching too. This happens if you 'svn add' the same dir in
both branches. Example:
Bad, causes conflict:
svn add ^/branches/foo/new_dir
svn add ^/branches/bar/new_dir
Good:
Svn add ^/branches/foo/new_dir
cd to bar workspace; svn copy ^/branches/foo/new_dir .
It could also happen if you renamed/moved the same dir in both branches.
> local unversioned, incoming add upon switch
This sounds like you have a normal, unversioned directory in the workspace. As
part of the switch, svn wants to add a versioned dir of the same name to your
workspace. You should be able to rename the local normal dir to a new name in
order to let the add operation be run unimpeded. I would 'svn revert -R' the
entire workspace[1], rename the normal, local dir, and re-run the switch. And
figure out why you have a normal, unversioned copy of the dir in the first
place.
> This may or may not be what is supposed to happen, that would be the first
> thing I would like to know. How to fix it would be the second thing that I
> would like to know. According to the help of the resolve command says:
>
> So I tried svn resolve -accept working LibraryDirectory but I believe that
> was a mistake because then the directory was marked "Delete" which is not
> what I wanted. Does anyone know what is the proper response?
Meh. Resolving tree conflicts is a bit of a manual process. IIRC, to resolve
it, you would need to
1) rename the normal, local dir, and
2) 'svn copy svn://server/.../LibraryDirectory .' Meaning, you need to manually
implement the add. ('svn switch' failed the add so you need to reproduce the
add manually.)
3) 'svn resolve' the dir.
Which is why I recommend just reverting[1] the switch, renaming the dir and
re-running the switch.
The main takeaway is that resolving tree conflicts isn't as easy as resolving
file conflicts. File conflicts let you use the 'mine-full', 'theirs-full',
etc. options, but tree conflicts do not. Fixing tree conflicts requires fixing
up the tree in the workspace yourself and then using 'svn resolve --accept
working' to tell subversion that the tree is now in the state you want. In
other words, you have to manually implement 'theirs-full'.
> I did not want to lose the library from the working copy so I switched back
> to the other branch and then switch back. Now it says:
> local delete, incoming delete upon switch
You (or the failed 'svn switch' command) ran 'svn delete some_dir' in your
workspace. However, the current 'svn switch' also wants to run 'svn delete
some_dir'. So svn switch is complaining that it can't delete the dir because
it's already flagged for deletion. =/
> It seems I did something wrong. My next step would be to add the library
> back, but that may not be the best response. Any suggestions?
It sounds like you mangled the switch with too many hacks while trying to fix
it, i.e. the workspace is a mess. Just 'svn revert -R'[1], then 'svn status'
to make sure that there are no local/private files that could muck up the
switch.
The thing to remember is that svn is replaying changes on top of your
workspace. It walks the revisions, and for each revision, applies that
revision's changes to the workspace. So if you're applying 10 revisions' worth
of changes and the second revision breaks the switch/merge with a tree
conflict, then you have to manually fix the tree conflict (svn add, svn rm, svn
revert, etc.), resolve it, and then re-run the switch/merge to apply the
renaming 8 revisions.
[1] Before you run 'svn revert -R', run 'svn status' to make sure you don't
have any modified, uncommitted files that you really care about. Revert will
delete those changes.
Re: server config
On 8/19/2013 6:19 PM, Ben Reser wrote: On 8/19/13 9:07 AM, Scott Frankel wrote: I'm new to SVN server configuration and find myself setting up a CentOS 6.4 server with svn version 1.6.1, following the red-bean book. I'd strongly urge you not to use 1.6.1, see the list of applicable security issues here: http://subversion.apache.org/security/ If you're using the CentOS packages they may have patched those issues without updating the svn version number. You should check that though. If you're setting a new server I wouldn't start with 1.6.x but would go straight to 1.7.x or 1.8.x, probably 1.8.x if you can. For the 1.8.1 RPMs, I suggest adding the WANDisco repository to your configuration. http://www.wandisco.com/subversion/download What you're looking for is "Download Subversion Installer V1.8.1 for Redhat". You download a shell script which then needs to be executed to install the WANDisco repositories and install the SVN 1.8.1 RPMs.
Re: server config
On 8/20/2013 1:19 AM, olli hauer wrote: On 2013-08-20 01:41, Nico Kadel-Garcia wrote: I think he meant "subversion-1.6.11", which is the default version for CentOS 6.4. Check the SELinux settings in /etc/sysconfig/selinux. Set the line to 'SELINUX=permissive' (or disabled) After changing the SELINUX value a reboot is required Additional add a trailing '/' so you config looks so. A better way to handle SELinux issues is to: # getenforce - To see whether you are in permissive or enforcing mode # setenforce permissive - Run this before doing your tests Then use the various SELinux troubleshooting tools to see what errors were logged while in permissive mode. Once you have fixed your issues, you can use "setenforce enforcing" and then re-run your tests. The command line troubleshooting tool is: # sealert -a /var/log/audit/audit.log
Re: checkout / update problem: svn: Malformed XML: not well-formed (invalid token) at line ...
markbeezhold writes: > Issue 2730 needs to be re-visited!!! > (http://subversion.tigris.org/issues/show_bug.cgi?id=2730) > I relocated an SVN repository, and shortly thereafter began seeing the > "Issue 2730" problem. > What a "PAIN"... Every time I do an "svn commit," the log-file inserts the > same non-ASCII characters into the user-name value along with a valid > user-name. I have to do an "svnadmin setrevprop" to fix the incoming > version's "svn:author" property, and edit the update's log-file to remove > the non-ASCII characters. > Most lately, something has become so messed-up, that SVN adds a file, then > breaks because of the the mal-formed XML problem, and then refuses to accept > the file it had just added. Even the --force option does not help... I > cannot break out of this cleanup/update cycle, now, no matter what I try. If you have log files then you are using a 1.6 client which is unlikely to get fixed. The 1.8 client will probably handle things better. There is a problem with non-XML characters affecting some operations, I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4415 -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Issue 4039
Yes, I have "subst M: C:\SomeDir\Project\subdir", but thanks for the feedback. With "subst M: C:\SomeDir\Project", works very well indeed 2013/8/19 Johan Corveleyn > On Mon, Aug 19, 2013 at 9:25 PM, Angelo Tavares > wrote: > > My case is creating subst working areas, which is not presented the > features > > of subversion. > > > > Can you please give a bit more detail? What do you mean by "creating > subst working areas"? > > Do you mean, for instance, that you have a working copy in > C:\SomeDir\Project (which is the root of the working copy), and you > execute "subst M: C:\SomeDir\Project"? If so, that works fine (just > tried it with 1.7 and 1.8). > > But if you want "subst M: C:\SomeDir\Project\subdir", that won't work, > and like Ivan said, will probably never be fixed (it really doesn't > fit with the working copy design of 1.7+, where all SVN metadata is > centralized in the root of the working copy). > > -- > Johan >
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tuesday, August 20, 2013 12:15:32 PM UTC+2, Ivan Zhakov wrote: > > On Tue, Aug 20, 2013 at 2:05 PM, > > wrote: > > On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote: > >>> > >>> On Tue, Aug 20, 2013 at 12:20 PM, wrote: > >>> > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: > >>> >> > >>> >> I did not find a solution however I wrote an monitor application > that > >>> >> checks if the httpd.exe process hits 100%, if so I KILL the process > >>> >> and > >>> >> CollabNet then restarts another instance. > >>> > > Last night the problem occurred again, this time I had debug logging > enabled > > for apache, and left it running for a while. > > > > Error log shows last succesfull requests at 19:51. Some hours later all > > apache threads are busy, as reported in the error log: > > > > Mon Aug 19 19:51:49.378688 2013] [authz_core:debug] [pid 568:tid 932] > > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > > result of : denied (no authenticated user yet) > > [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] > > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > > result of Require valid-user : denied (no authenticated user yet) > > [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] > > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > > result of : denied (no authenticated user yet) > > [Mon Aug 19 19:51:51.660084 2013] [authnz_ldap:debug] [pid 568:tid 932] > > mod_authnz_ldap.c(500): [client 172.17.1.15:2283] AH01691: auth_ldap > > authenticate: using URL > > ldap://172.17.1.1:3268/DC=isaac,DC=local?sAMAccountName?sub > > [Mon Aug 19 21:06:55.298940 2013] [mpm_winnt:error] [pid 568:tid 964] > > AH00326: Server ran out of threads to serve requests. Consider raising > the > > ThreadsPerChild setting > As I replied you privately I cannot investigate provided dumps because > you're using CollabNet distribution and I don't have access to PDB > files required for crash dumps debugging. > > But from what I see process is stuck in > libaprutil-1.dll!7489fc50(), given the last message in debug > log is "auth_ldap authenticate: using URL" it most likely problem with > communication with LDAP server (ldap protocol implemented in > libapr-util). It could be misconfiguration or bug in libapr-util. > > With subversion edge 3.x we used to have the same problem, until I changed the ldap settings to connect to AD port 3268 instead of 389. With 3268 the problem was solved. But in subversion edge 4.x the problem is back, probably because of the upgrade to apache 2.4 We have had other problems with apache 2.4 on windows.
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tue, Aug 20, 2013 at 2:05 PM, wrote: > On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote: >>> >>> On Tue, Aug 20, 2013 at 12:20 PM, wrote: >>> > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: >>> >> >>> >> I did not find a solution however I wrote an monitor application that >>> >> checks if the httpd.exe process hits 100%, if so I KILL the process >>> >> and >>> >> CollabNet then restarts another instance. >>> > Last night the problem occurred again, this time I had debug logging enabled > for apache, and left it running for a while. > > Error log shows last succesfull requests at 19:51. Some hours later all > apache threads are busy, as reported in the error log: > > Mon Aug 19 19:51:49.378688 2013] [authz_core:debug] [pid 568:tid 932] > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > result of : denied (no authenticated user yet) > [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > result of Require valid-user : denied (no authenticated user yet) > [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] > mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization > result of : denied (no authenticated user yet) > [Mon Aug 19 19:51:51.660084 2013] [authnz_ldap:debug] [pid 568:tid 932] > mod_authnz_ldap.c(500): [client 172.17.1.15:2283] AH01691: auth_ldap > authenticate: using URL > ldap://172.17.1.1:3268/DC=isaac,DC=local?sAMAccountName?sub > [Mon Aug 19 21:06:55.298940 2013] [mpm_winnt:error] [pid 568:tid 964] > AH00326: Server ran out of threads to serve requests. Consider raising the > ThreadsPerChild setting As I replied you privately I cannot investigate provided dumps because you're using CollabNet distribution and I don't have access to PDB files required for crash dumps debugging. But from what I see process is stuck in libaprutil-1.dll!7489fc50(), given the last message in debug log is "auth_ldap authenticate: using URL" it most likely problem with communication with LDAP server (ldap protocol implemented in libapr-util). It could be misconfiguration or bug in libapr-util. -- Ivan Zhakov
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote: > On Tue, Aug 20, 2013 at 12:20 PM, wrote: >> > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: >> >> >> >> I did not find a solution however I wrote an monitor application that >> >> checks if the httpd.exe process hits 100%, if so I KILL the process >> and >> >> CollabNet then restarts another instance. >> >> Last night the problem occurred again, this time I had debug logging enabled for apache, and left it running for a while. Error log shows last succesfull requests at 19:51. Some hours later all apache threads are busy, as reported in the error log: Mon Aug 19 19:51:49.378688 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of : denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authz_core:debug] [pid 568:tid 932] mod_authz_core.c(799): [client 172.17.1.15:2283] AH01626: authorization result of : denied (no authenticated user yet) [Mon Aug 19 19:51:51.660084 2013] [authnz_ldap:debug] [pid 568:tid 932] mod_authnz_ldap.c(500): [client 172.17.1.15:2283] AH01691: auth_ldap authenticate: using URL ldap://172.17.1.1:3268/DC=isaac,DC=local?sAMAccountName?sub [Mon Aug 19 21:06:55.298940 2013] [mpm_winnt:error] [pid 568:tid 964] AH00326: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting [Mon Aug 19 21:06:56.299004 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:01.549340 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:06.830928 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:12.159394 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:17.440982 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:22.722570 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second [Mon Aug 19 21:07:28.129166 2013] [mpm_winnt:debug] [pid 568:tid 964] child.c(187): AH00327: mpm_get_completion_context: Failed to get a free context within 1 second
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tuesday, August 20, 2013 10:47:22 AM UTC+2, Ivan Zhakov wrote: > > On Tue, Aug 20, 2013 at 12:20 PM, > > wrote: > > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: > >> > >> I did not find a solution however I wrote an monitor application that > >> checks if the httpd.exe process hits 100%, if so I KILL the process and > >> CollabNet then restarts another instance. > > > > Is it something you'd like to share? > > > > I used ProcDump to create a dump when the process went to 100%. Would it > be > > usefull to post it here? > > > Could you post just call stack here? > > I just sent you an email with the dump.Not sure if a process dump can contain confidential data.
Re: Subversion 1.8 httpd.exe taking 100% CPU
valentijnschol...@gmail.com wrote on Tue, Aug 20, 2013 at 01:20:42 -0700: > I used ProcDump to create a dump when the process went to 100%. Would it be > usefull to post it here? Please don't post large binary attachments to this list. Upload them somewhere and (after ensuring they don't contain passwords, etc) post a link to them.
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Tue, Aug 20, 2013 at 12:20 PM, wrote: > On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: >> >> I did not find a solution however I wrote an monitor application that >> checks if the httpd.exe process hits 100%, if so I KILL the process and >> CollabNet then restarts another instance. > > Is it something you'd like to share? > > I used ProcDump to create a dump when the process went to 100%. Would it be > usefull to post it here? > Could you post just call stack here? -- Ivan Zhakov
Re: Subversion 1.8 httpd.exe taking 100% CPU
On Monday, August 19, 2013 5:41:55 PM UTC+2, Dinesh Hirani wrote: > I did not find a solution however I wrote an monitor application that > checks if the httpd.exe process hits 100%, if so I KILL the process and > CollabNet then restarts another instance. > Is it something you'd like to share? I used ProcDump to create a dump when the process went to 100%. Would it be usefull to post it here?
Re: Cannot check out public directory with client 1.8.x without access to repo root
On Mon, Aug 19, 2013 at 11:14 PM, Ivan Zhakov wrote: > On Mon, Aug 19, 2013 at 10:19 PM, Mark Tsuchida > wrote: >> Hello, >> >> I'm having an issue with our partially-public SVN repository. >> >> The server is running SVN 1.6.11 (CentOS 6.4) with Apache and TLS. >> Our repository (let's call it "myrepo") allows public read access (* = >> r) to myrepo/trunk, but not to myrepo/ (the root). There is also a >> directory myrepo/trunk/secret to which only specific users have access >> to. >> >> Everything has been working as expected with SVN 1.6 and 1.7 clients: >> in particular, no username or password is requested when checking out >> myrepo/trunk. >> >> However, with SVN 1.8.0 and 1.8.1 clients, it is not possible to check >> out any directory without supplying the credentials of a user who has >> access to the repository root. >> >> svn co https://our.server.com/svn/myrepo/trunk -> Requires >> authentication with client 1.8.x but not with 1.6.x or 1.7.x >> svn list https://our.server.com/svn/myrepo/trunk -> Works even with 1.8.1 >> svn list https://our.server.com/svn/myrepo -> Requires auth, as expected >> >> The 1.8.x clients can successfully check out myrepo/trunk if a >> username and password are given, for a user with access to the >> repository root. >> >> I have so far been unable to reproduce this with a simplified test >> repository, so any hints as to where to look would be much >> appreciated. >> >> The following is the section of ssl_access_log produced by checking >> out myrepo/trunk using client 1.6.18 (OS X): >> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "OPTIONS >> /svn/myrepo/trunk HTTP/1.1" 200 197 > [...] >> /svn/myrepo/!svn/vcc/default HTTP/1.1" 207 420 >> xx.xx.xx.xx - - [16/Aug/2013:17:36:35 -0700] "PROPFIND >> /svn/myrepo/!svn/bln/123 HTTP/1.1" 207 479 >> >> And the following is the section of ssl_access_log produced by >> checking out myrepo/trunk using client 1.8.1 (TortoiseSVN on Windows >> 7): >> xx.xx.xx.xx - - [16/Aug/2013:17:34:05 -0700] "OPTIONS >> /svn/myrepo/trunk HTTP/1.1" 200 197 > [...] >> xx.xx.xx.xx - - [16/Aug/2013:17:34:06 -0700] "PROPFIND >> /svn/myrepo/!svn/bc/123 HTTP/1.1" 401 483 It should be "403 Forbidden", not "401 Unauthorized". Looks like some issue with server configuration. >> >> It appears that the 1.8.1 client requests /svn/myrepo/!svn/bc/123, to >> which access is denied (401), whereas client 1.6.18 only ever requests >> /svn/myrepo/!svn/bc/123/trunk, to which access is granted. >> > Most likely it is some problem with inherited properties feature > implemented in Subversion 1.8. > The issue doesn't reproduces with server configured for non-anonymous access: the server returns 401 Forbidden for PROPFIND request on repository root and handled properly by Subversion 1.8 client. -- Ivan Zhakov CTO | VisualSVN | http://www.visualsvn.com
